New Proposed policy for Externally-Operated subCAs

449 views
Skip to first unread message

Kathleen Wilson

unread,
Mar 16, 2012, 5:07:58 PM3/16/12
to mozilla-dev-s...@lists.mozilla.org
This is long, so please bear with me and read all the way through before
passing judgement.

As you all know, we have been working towards a policy for
externally-operated subCAs that will provide a reasonable compromise
between those who want all subCAs to be publicly disclosed and audited,
and those who need to support externally-operated subCAs for large
enterprise customers.

I have been looking for ways that an externally-operated subCA
certificate can be technically constrained that will satisfy those who
are demanding auditing and disclosure of all subCAs. It appears that the
only way to accomplish this will be for an extension/constraint to be
specified in the intermediate certificate and controlled by crypto code
(e.g. NSS for Mozilla). I believe there are two ways that an
externally-operated subordinate CA certificate will need to be
constrained. First, the key usage of the certificates that the
externally-operated certificate signs must be controlled. Second,
externally-operated subCA certificates that can sign SSL and S/MIME
certificates need to include name constraints.

In regards to limiting the key usage of certificates signed by an
externally-operated subordinate CA certificate, I believe there are two
potential ways that this could be done. One way would be to standardize
on a set of Policy OIDs for things like SSL and S/MIME. However, I think
this would be difficult to achieve, and if this were a viable option,
then I think that there would have been a standard EV Policy OID. The
other way is to use Extended Key Usage (EKU).

The proposal is that the EKU would be specified in the intermediate
certificates, and the crypto code would look up the certificate chain at
the EKU extensions to make sure that the end-entity certificate is
allowed to be used for that purpose. The old NSS code does this if the
EKU extension is present in the intermediate certificate, but the new
libpkix code doesn’t currently do this. Ryan Hurst has filed a bug
requesting that this behavior be added to libpkix:
https://bugzilla.mozilla.org/show_bug.cgi?id=725351

I understand that RFC 5280 does not require the EKUs be consistent
through the certificate hierarchy. However, I have been unable to find
another viable solution to restricting the key usage of certificates
issued by externally-operated subCAs.

I propose that we consider using EKU in this way and requiring it in
Mozilla’s CA Certificate Policy for externally-operated subordinate CAs.
If we agree to go in this direction, then I believe it would be fine to
first add the requirement to Mozilla’s CA Certificate Policy, and then
follow with updating the code in NSS libpkix to enforce it.

I would like to submit the following text for consideration to replace
the currently proposed text in #9 of
http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html

--
9. Each externally-operated subordinate CA must either be audited in
accordance with Mozilla’s CA Certificate Policy or must be technically
constrained.

- Each externally-operated subordinate CA that is not technically
constrained must be publicly disclosed, along with the subordinate CA's
corresponding Certificate Policy or Certification Practice Statement and
public attestation of the subordinate CA's conformance to the stated
certificate verification requirements and other operational criteria by
a competent independent party or parties with access to details of the
subordinate CA's internal operations. The subordinate CA's certificate
verification requirements and operational criteria must satisfy the
requirements of Mozilla's CA Certificate Policy. The CA's Certificate
Policy or Certification Practice Statement must indicate where the list
of publicly disclosed subordinate CAs may be found on the CA's website.

- For an externally-operated subordinate CA to be considered technically
constrained, the subordinate CA certificate (and any intermediate
certificates chaining up to that certificate) must include an Extended
Key Usage (EKU) extension specifying the key usage of the certificates
it can sign.

-- If the EKU includes "TLS WWW server authentication" then the
certificate must also include X.509 dNSName Name Constraints as
specified in RFC 5280, and the Name Constraints must only include
domains for which the CA has confirmed that the subordinate CA has
registered or has been authorized by the domain registrant to act on the
registrant's behalf.

-- If the EKU includes "Email protection" then the certificate must also
include rfc822Name Name Constraints as specified in RFC 5280, and the
Name Constraints must only include email addresses or mailboxes for
which the CA has confirmed that the subordinate CA is authorized to use.

-- The CA must also have additional technical and/or contractual
restrictions in place to ensure that the subordinate CA fully complies
with Mozilla's CA Certificate Policy. Such controls must be documented
in the CA's Certificate Policy or Certification Practice Statement, and
reviewed by a competent independent party as part of the CA's annual audit.

-- Alternate methods of technical controls must be publicly reviewed and
approved, according to Mozilla’s process that begins with submitting a
bug report into the mozilla.org Bugzilla system, filed against the "CA
Certificates" component of the "mozilla.org" product. Mozilla's wiki
page, <page link>, provides further details about how to submit a formal
request.
--


If this (or some version of this) new text gains acceptance, then we
will discuss the timeline for when the new policy updates would be
enforced. For example, the new policy would apply to all new
externally-operated subCA certificates, and all old externally-operated
subCA certificates would need to be updated by <some reasonable date>.

I will greatly appreciate your thoughtful and constructive input into
this proposal.

Kathleen

ianG

unread,
Mar 17, 2012, 12:24:59 AM3/17/12
to dev-secur...@lists.mozilla.org
On 17/03/12 08:07 AM, Kathleen Wilson wrote:
> This is long, so please bear with me and read all the way through before
> passing judgement.

No longer than mine :) serious proposals need a lot of flesh and meat.


> - For an externally-operated subordinate CA to be considered technically
> constrained, the subordinate CA certificate (and any intermediate
> certificates chaining up to that certificate) must include an Extended
> Key Usage (EKU) extension specifying the key usage of the certificates
> it can sign.
>
> -- If the EKU includes "TLS WWW server authentication" then the
> certificate must also include X.509 dNSName Name Constraints as
> specified in RFC 5280, and the Name Constraints must only include
> domains for which the CA has confirmed that the subordinate CA has
> registered or has been authorized by the domain registrant to act on the
> registrant's behalf.
>
> -- If the EKU includes "Email protection" then the certificate must also
> include rfc822Name Name Constraints as specified in RFC 5280, and the
> Name Constraints must only include email addresses or mailboxes for
> which the CA has confirmed that the subordinate CA is authorized to use.


I get the sense of the above and it seems on first reading to be ok, for
what it says.

What it doesn't say or I am missing is what happens with constraints not
recognised above (TLS & email)? Does this mean that the above two
key-usage constraints are the only ones permitted, or that any other
key-usage constraints can be employed without further constraints on
name spaces?



iang

Rob Stradling

unread,
Mar 19, 2012, 6:27:44 AM3/19/12
to Kathleen Wilson, mozilla-dev-s...@lists.mozilla.org
Hi Kathleen.

<snip>
> I propose that we consider using EKU in this way and requiring it in
> Mozilla’s CA Certificate Policy for externally-operated subordinate
> CAs.

You mention externally-operated Sub-CAs specifically. Does this mean
that internally-operated Sub-CAs will _not_ be required to include the
EKU extension?

If so, the proposed changes to libpkix will need to be able to enforce
the new rules for externally-operated Sub-CAs only. But how would the
libpkix code be able to tell the difference between an
internally-operated Sub-CA and an externally-operated Sub-CA?

By just looking at a Sub-CA certificate, you can't tell who is in
control of the private key. It might be "externally-operated" by the
organization identified in the Sub-CA certificate, or it might be
"internally-operated" by the organization who issued the Sub-CA certificate.

Some options...

1. Scrap the idea of libpkix requiring the EKU extension to be present
in Sub-CA certificates.
or
2. Require all Sub-CA certificates (internally-operated and
externally-operated) to have the EKU extension.
or
3. Define a "Private Key Holder" certificate extension that the Issuing
CA can include in the Sub-CA certificate, which would clearly identify
which party controls the private key.

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

Kathleen Wilson

unread,
Mar 19, 2012, 1:29:30 PM3/19/12
to mozilla-dev-s...@lists.mozilla.org
On 3/16/12 9:24 PM, ianG wrote:
>> - For an externally-operated subordinate CA to be considered technically
>> constrained, the subordinate CA certificate (and any intermediate
>> certificates chaining up to that certificate) must include an Extended
>> Key Usage (EKU) extension specifying the key usage of the certificates
>> it can sign.
>>
>> -- If the EKU includes "TLS WWW server authentication" then the
>> certificate must also include X.509 dNSName Name Constraints as
>> specified in RFC 5280, and the Name Constraints must only include
>> domains for which the CA has confirmed that the subordinate CA has
>> registered or has been authorized by the domain registrant to act on the
>> registrant's behalf.
>>
>> -- If the EKU includes "Email protection" then the certificate must also
>> include rfc822Name Name Constraints as specified in RFC 5280, and the
>> Name Constraints must only include email addresses or mailboxes for
>> which the CA has confirmed that the subordinate CA is authorized to use.
>>
>>
>> -- The CA must also have additional technical and/or contractual
>> restrictions in place to ensure that the subordinate CA fully complies
>> with Mozilla's CA Certificate Policy. Such controls must be documented
>> in the CA's Certificate Policy or Certification Practice Statement, and
>> reviewed by a competent independent party as part of the CA's annual audit.
>
> I get the sense of the above and it seems on first reading to be ok, for
> what it says.
>
> What it doesn't say or I am missing is what happens with constraints not
> recognised above (TLS & email)? Does this mean that the above two
> key-usage constraints are the only ones permitted, or that any other
> key-usage constraints can be employed without further constraints on
> name spaces?
>


Other key usages are permitted. For example, if there is an
externally-operated subCA certificate that can only sign certificates
for timestamping, then only the timestamping EKU should be included, and
the CA should also have additional technical and/or contractual
restrictions in place for that subCA.

The proposed code update for libpkix is that NSS would not accept an SSL
certificate that is signed by an intermediate certificate that has
timestamping (and not server authentication) in its EKU.

Kathleen

Kathleen Wilson

unread,
Mar 19, 2012, 2:41:55 PM3/19/12
to mozilla-dev-s...@lists.mozilla.org
On 3/19/12 3:27 AM, Rob Stradling wrote:
> Hi Kathleen.
>
> <snip>
>> I propose that we consider using EKU in this way and requiring it in
>> Mozilla’s CA Certificate Policy for externally-operated subordinate
>> CAs.
>
> You mention externally-operated Sub-CAs specifically. Does this mean
> that internally-operated Sub-CAs will _not_ be required to include the
> EKU extension?
>

I don't believe it would be reasonable to require EKUs in all
internally-operated intermediate certificates.

When a CA is audited the operations of their root certificates that are
included in NSS and all of their internally-operated intermediate
certificates should be evaluated as part of the audit.


> If so, the proposed changes to libpkix will need to be able to enforce
> the new rules for externally-operated Sub-CAs only. But how would the
> libpkix code be able to tell the difference between an
> internally-operated Sub-CA and an externally-operated Sub-CA?
>

When the EKU extension is not specified in the intermediate certificate,
then the key usage of the certificates it signs will not be restricted.

NSS code cannot tell the difference between an internally-operated
intermediate certificate and an externally-operated intermediate
certificate.

The requirement for EKU in externally-operated subCA certificates will
be in policy, and is auditable.


> By just looking at a Sub-CA certificate, you can't tell who is in
> control of the private key. It might be "externally-operated" by the
> organization identified in the Sub-CA certificate, or it might be
> "internally-operated" by the organization who issued the Sub-CA
> certificate.
>
> Some options...
>
> 1. Scrap the idea of libpkix requiring the EKU extension to be present
> in Sub-CA certificates.
> or
> 2. Require all Sub-CA certificates (internally-operated and
> externally-operated) to have the EKU extension.
> or
> 3. Define a "Private Key Holder" certificate extension that the Issuing
> CA can include in the Sub-CA certificate, which would clearly identify
> which party controls the private key.
>

I see the point that the requirement as currently proposed wouldn't
apply to managed-services in which the CA operates the subCA's
certificate and provides a user interface for the customer to issue
certificates.

At one point I had the following text to take this into account:
"Each externally-operated subordinate CA must either be audited in
accordance with Mozilla’s CA Certificate Policy or must be technically
constrained. This includes any external third party that can directly
cause the issuance of a certificate."

I deleted the second sentence because I thought it was confusing.
However, I think something along those lines does need to be added. Even
if the service is a managed-service, the subCA's certificate should
still be restricted in this way.

How about this:
"9. Each externally-operated subordinate CA must either be audited in
accordance with Mozilla’s CA Certificate Policy or must be technically
constrained. Any external third party that can directly cause the
issuance of a certificate must be treated as an externally-operated
subordinate CA, even if the private key is controlled by the CA."

Kathleen












Eddy Nigg

unread,
Mar 19, 2012, 3:11:28 PM3/19/12
to mozilla-dev-s...@lists.mozilla.org
On 03/19/2012 08:41 PM, From Kathleen Wilson:
> How about this:
> "9. Each externally-operated subordinate CA must either be audited in
> accordance with Mozilla’s CA Certificate Policy or must be technically
> constrained. Any external third party that can directly cause the
> issuance of a certificate must be treated as an externally-operated
> subordinate CA, even if the private key is controlled by the CA."

Aren't the requirements that Microsoft and also the BR attempts to set
forth sufficient in order to prevent certain abuse? Because if it's a
hosted model, then the CA also must implement control for domain control
validation at the least and this is audited by the parent CA and
probably the reason for having a hosted model in first place.

"Directly cause the issuance" in this context should be a sign of the
past where an RA or other entity could request a certificate for
google.com and it would have been issued by the CA without further
checking. In my opinion domain control validation is a requirement for
any CA anywhere no matter which model, but with a hosted model it's
under the control and responsibility of the parent CA.

If the above suggestion will be adopted, there will be no benefit for
CAs to use a more controlled model and rather give out the keys and
responsibility - probably exactly the opposite of what the editor wants
to achieve.

--
Regards

Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg


Kathleen Wilson

unread,
Mar 19, 2012, 4:44:24 PM3/19/12
to mozilla-dev-s...@lists.mozilla.org
Oops.You are correct. The case of the managed-service is handled by BR
11.1, BR 14.2.4, and BR 17.5.

I will re-delete that second sentence.

Kathleen

Phillip Hallam-Baker

unread,
Mar 19, 2012, 5:03:28 PM3/19/12
to Kathleen Wilson, mozilla-dev-s...@lists.mozilla.org
Related to these constraints, is there a (viable) way to state in PKIX
speak 'this cert is allowed to sign EE certs but not cert signing
certs' ? I know we had discussions on doing that in PKIX but only
sometimes do those ideas make it into code.

I would like to have a set of criteria for managing PKI where an
auditor can be given simple things to check for such as:

"If the cert can sign other cert signing certs it MUST NOT be online'
'If an intermediate is an online cert it MUST NOT be capable of
signing cert signing certs'


The motivation for this would be to prevent the type of compromise
where the attacker gains unrestricted logical access to an online HSM
and uses it to create either an OCSP signing cert or a cert signing
cert.

I am less worried by the likelihood of an undetected physical breach
of an offline HSM. Those can be managed through separation of duties
controls etc.


I would also like the checks to be enforced by the HSM itself. But
that is a different matter. I like to have redundant controls (and
lots of them).

Kathleen Wilson

unread,
Mar 19, 2012, 5:08:16 PM3/19/12
to mozilla-dev-s...@lists.mozilla.org
Following up on Rob's comments:

> Some options...
> 1. Scrap the idea of libpkix requiring the EKU extension to be
> present in Sub-CA certificates.

I think there is value in having policy about requiring the EKU in
externally-operated subCA certificates, and this is auditable.

> or
> 2. Require all Sub-CA certificates (internally-operated and
> externally-operated) to have the EKU extension.

I don't think it is reasonable to require all internally-operated
intermediate certificates to have the EKU extension.

> or
> 3. Define a "Private Key Holder" certificate extension that the
> Issuing CA can include in the Sub-CA certificate, which would clearly
> identify which party controls the private key.

Would this additional extension add value? We would still have to rely
on the CA to add this extension and specify it correctly when the subCA
cert is externally-operated, and rely on auditing to check (e.g. there
still wouldn't be a way for NSS to confirm that an intermediate
certificate with or without this extension is internally-operated).

Would that be any better than relying on the CA to specify the EKU when
the subCA cert is externally-operated, and relying on the auditing to check?

Kathleen

Phillip Hallam-Baker

unread,
Mar 19, 2012, 5:14:35 PM3/19/12
to Kathleen Wilson, mozilla-dev-s...@lists.mozilla.org
On Mon, Mar 19, 2012 at 5:08 PM, Kathleen Wilson <kwi...@mozilla.com> wrote:
> Following up on Rob's comments:
>

>> 3. Define a "Private Key Holder" certificate extension that the
>> Issuing CA can include in the Sub-CA certificate, which would clearly
>> identify which party controls the private key.
>
> Would this additional extension add value? We would still have to rely on
> the CA to add this extension and specify it correctly when the subCA cert is
> externally-operated, and rely on auditing to check (e.g. there still
> wouldn't be a way for NSS to confirm that an intermediate certificate with
> or without this extension is internally-operated).
>
> Would that be any better than relying on the CA to specify the EKU when the
> subCA cert is externally-operated, and relying on the auditing to check?

It would be an auditable control which would be a win in itself.

One of the things I think DigiNotar shows is that the auditors don't
know what they should be looking for and lets face it, PKIX does not
exactly give them much help.


Today we have three components in the system that each think that they
are doing the right thing. The problem is that none of the pieces
quite join up like they should and those gaps are where the bad guys
can take a jackhammer and tear them apart.

--
Website: http://hallambaker.com/

Erwann Abalea

unread,
Mar 19, 2012, 5:27:00 PM3/19/12
to mozilla-dev-s...@lists.mozilla.org
Le lundi 19 mars 2012 22:03:28 UTC+1, Phillip Hallam-Baker a écrit :
> Related to these constraints, is there a (viable) way to state in PKIX
> speak 'this cert is allowed to sign EE certs but not cert signing
> certs' ? I know we had discussions on doing that in PKIX but only
> sometimes do those ideas make it into code.

basicConstraints ca:TRUE pathLen:0, critical.

> The motivation for this would be to prevent the type of compromise
> where the attacker gains unrestricted logical access to an online HSM
> and uses it to create either an OCSP signing cert or a cert signing
> cert.

An designated OCSP responder is not a CA cert, and can't sign certs, so this is not a viable defense.

Phillip Hallam-Baker

unread,
Mar 19, 2012, 7:28:36 PM3/19/12
to Erwann Abalea, mozilla-dev-s...@lists.mozilla.org
On Mon, Mar 19, 2012 at 5:27 PM, Erwann Abalea <eab...@gmail.com> wrote:
> Le lundi 19 mars 2012 22:03:28 UTC+1, Phillip Hallam-Baker a écrit :
>> Related to these constraints, is there a (viable) way to state in PKIX
>> speak 'this cert is allowed to sign EE certs but not cert signing
>> certs' ? I know we had discussions on doing that in PKIX but only
>> sometimes do those ideas make it into code.
>
> basicConstraints ca:TRUE pathLen:0, critical.

OK, yes duh, should have thought of that. Like that is what it is for


>> The motivation for this would be to prevent the type of compromise
>> where the attacker gains unrestricted logical access to an online HSM
>> and uses it to create either an OCSP signing cert or a cert signing
>> cert.
>
> An designated OCSP responder is not a CA cert, and can't sign certs, so this is not a viable defense.

But this narrows the problem to forcing the OCSP cert to be issued off
an offline root rather than an online one.

That could be achieved by putting a flag in the intermediate cert that
would state that any authoritative OCSP cert should be signed by the
same key as signs the intermediary.


BTW, I have no idea how we let this language get through in RFC 2560:

2.6 OCSP Signature Authority Delegation

The key that signs a certificate's status information need not be the
same key that signed the certificate. A certificate's issuer
explicitly delegates OCSP signing authority by issuing a certificate
containing a unique value for extendedKeyUsage in the OCSP signer's
certificate. This certificate MUST be issued directly to the
responder by the cognizant CA.



--
Website: http://hallambaker.com/

Kathleen Wilson

unread,
Mar 19, 2012, 8:19:10 PM3/19/12
to mozilla-dev-s...@lists.mozilla.org
On 3/19/12 4:28 PM, Phillip Hallam-Baker wrote:
> On Mon, Mar 19, 2012 at 5:27 PM, Erwann Abalea<eab...@gmail.com> wrote:
>> Le lundi 19 mars 2012 22:03:28 UTC+1, Phillip Hallam-Baker a �crit :
>>> Related to these constraints, is there a (viable) way to state in PKIX
>>> speak 'this cert is allowed to sign EE certs but not cert signing
>>> certs' ? I know we had discussions on doing that in PKIX but only
>>> sometimes do those ideas make it into code.
>>
>> basicConstraints ca:TRUE pathLen:0, critical.
>


At one point I was considering including something like the following in
the first paragraph of the new text:

�All externally-operated subordinate CA certificates must include
pathLenConstraint in the Basic Constraints extension, and the path
length must be consistent with the contract between the CA and the
subordinate CA.�

I didn't want to side-track the rest of the new text, but I'd be happy
to put it back in.


Kathleen

Erwann Abalea

unread,
Mar 19, 2012, 7:46:29 PM3/19/12
to mozilla-dev-s...@lists.mozilla.org
Le mardi 20 mars 2012 00:28:36 UTC+1, Phillip Hallam-Baker a écrit :
> >> The motivation for this would be to prevent the type of compromise
> >> where the attacker gains unrestricted logical access to an online HSM
> >> and uses it to create either an OCSP signing cert or a cert signing
> >> cert.
> >
> > An designated OCSP responder is not a CA cert, and can't sign certs, so this is not a viable defense.
>
> But this narrows the problem to forcing the OCSP cert to be issued off
> an offline root rather than an online one.

I don't see how.

> That could be achieved by putting a flag in the intermediate cert that
> would state that any authoritative OCSP cert should be signed by the
> same key as signs the intermediary.

Nothing exists to do that.

> BTW, I have no idea how we let this language get through in RFC 2560:
>
> 2.6 OCSP Signature Authority Delegation
>
> The key that signs a certificate's status information need not be the
> same key that signed the certificate. A certificate's issuer
> explicitly delegates OCSP signing authority by issuing a certificate
> containing a unique value for extendedKeyUsage in the OCSP signer's
> certificate. This certificate MUST be issued directly to the
> responder by the cognizant CA.

The certificate's issuer can delegate OCSP signing authority to a designated responder, and the certificate's issuer's issuer can't do anything to prevent that from happening. Moreover, paragraph 2.2 is clear about who can sign an OCSP response:
- the CA who issued the certificate in question
- a trusted responder (client configuration, not practical outside corporate use)
- a designated responder directly issued by the CA who issued the certificate in question.

The "grand father" CA can't play any role in here.

ianG

unread,
Mar 19, 2012, 10:06:32 PM3/19/12
to dev-secur...@lists.mozilla.org
On 19/03/12 21:27 PM, Rob Stradling wrote:
> Hi Kathleen.
>
> <snip>
> > I propose that we consider using EKU in this way and requiring it in
> > Mozilla’s CA Certificate Policy for externally-operated subordinate
> > CAs.
>
> You mention externally-operated Sub-CAs specifically. Does this mean
> that internally-operated Sub-CAs will _not_ be required to include the
> EKU extension?
>
> If so, the proposed changes to libpkix will need to be able to enforce
> the new rules for externally-operated Sub-CAs only. But how would the
> libpkix code be able to tell the difference between an
> internally-operated Sub-CA and an externally-operated Sub-CA?
>
> By just looking at a Sub-CA certificate, you can't tell who is in
> control of the private key. It might be "externally-operated" by the
> organization identified in the Sub-CA certificate, or it might be
> "internally-operated" by the organization who issued the Sub-CA
> certificate.
>
> Some options...
>
> 1. Scrap the idea of libpkix requiring the EKU extension to be present
> in Sub-CA certificates.
> or
> 2. Require all Sub-CA certificates (internally-operated and
> externally-operated) to have the EKU extension.
> or
> 3. Define a "Private Key Holder" certificate extension that the Issuing
> CA can include in the Sub-CA certificate, which would clearly identify
> which party controls the private key.
>



The proposed control is a policy / disclosure / action control, not one
that is externally verifiable.

The thing is, by agreeing to the policy (contract) the CA binds itself
to those conditions. It then follows them. If at a later time some
problem turns up, and it is related to a breach of the policy, then that
breach is the cause for dropping the root.

If however there is ambiguity in the policy which a lawyer can argue
about, then it will be so argued. No breach, no drop. So, for similar
example, Trustwave will argue that there is nothing in the contract that
bans MITM.

The absence of any statement in the past about what a sub-CA was or
meant is that sort of loophole. One group of people claim that the
sub-CA is entirely the responsibility of the CA. Another group of
people claim that the sub-CA was sold to some other organisation and
therefore is no longer the CA's responsibility.

This is the sort of ambiguity that lawyers can argue a "pass" from. So
the strategy is to close the loopholes by disclosures and contracts
which lay out that the CA knew the loophole was not permitted. If they
then go and do it, then they hang themselves.

This strategy of course has its pluses and minuses. The point we're
making here is that contracts are agreed and choices are disclosed up
front, while discovery of breach will be by unknown means in the future.
Libpkix isn't the issue.



iang

ianG

unread,
Mar 19, 2012, 10:09:07 PM3/19/12
to dev-secur...@lists.mozilla.org
On 20/03/12 08:14 AM, Phillip Hallam-Baker wrote:

> Today we have three components in the system that each think that they
> are doing the right thing. The problem is that none of the pieces
> quite join up like they should and those gaps are where the bad guys
> can take a jackhammer and tear them apart.
>

What Phillip said!


iang

Ned Ulbricht

unread,
Mar 20, 2012, 6:28:33 AM3/20/12
to dev-secur...@lists.mozilla.org
On 03/19/2012 10:06 PM, ianG wrote:

> The thing is, by agreeing to the policy (contract) the CA binds itself
> to those conditions.

Ummm... this assertion makes me very, very uncomfortable.

Excuse me if this has been covered already, but I've got some real
basic, preliminary questions:

* Who are the parties to this (alleged) contract?
* Where and When was this (alleged) contract formed?
* Which body of law governs this (alleged) contract?

Of course, one typical purpose behind a contract is to keep the parties
out of court. But still, potentially:

* What court are we in?

--
Ned Ulbricht
mailto:ne...@netscape.net

Rob Stradling

unread,
Mar 20, 2012, 6:34:25 AM3/20/12
to Kathleen Wilson, mozilla-dev-s...@lists.mozilla.org
Hi Kathleen.

You wrote:
"I propose that we consider using EKU in this way and requiring it in
Mozilla’s CA Certificate Policy for externally-operated subordinate CAs.
If we agree to go in this direction, then I believe it would be fine to
first add the requirement to Mozilla’s CA Certificate Policy, and then
follow with updating the code in NSS libpkix to enforce it."

It seems I misunderstood what you meant by "code...enforce it".

Thanks for clarifying that libpkix will not be coded to reject CA
certificates that do not contain the EKU extension.

On 19/03/12 21:08, Kathleen Wilson wrote:
> Following up on Rob's comments:
>
> > Some options...
> > 1. Scrap the idea of libpkix requiring the EKU extension to be
> > present in Sub-CA certificates.
>
> I think there is value in having policy about requiring the EKU in
> externally-operated subCA certificates, and this is auditable.
>
> > or
> > 2. Require all Sub-CA certificates (internally-operated and
> > externally-operated) to have the EKU extension.
>
> I don't think it is reasonable to require all internally-operated
> intermediate certificates to have the EKU extension.
>
> > or
> > 3. Define a "Private Key Holder" certificate extension that the
> > Issuing CA can include in the Sub-CA certificate, which would clearly
> > identify which party controls the private key.
>
> Would this additional extension add value? We would still have to rely
> on the CA to add this extension and specify it correctly when the subCA
> cert is externally-operated, and rely on auditing to check (e.g. there
> still wouldn't be a way for NSS to confirm that an intermediate
> certificate with or without this extension is internally-operated).
>
> Would that be any better than relying on the CA to specify the EKU when
> the subCA cert is externally-operated, and relying on the auditing to
> check?
>
> Kathleen
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
3rd Floor, 26 Office Village, Exchange Quay,
Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed. If you have received this email in error please notify the
sender by replying to the e-mail containing this attachment. Replies to
this email may be monitored by COMODO for operational or business
reasons. Whilst every endeavour is taken to ensure that e-mails are free
from viruses, no liability can be accepted and the recipient is
requested to use their own virus checking software.

ianG

unread,
Mar 20, 2012, 8:09:13 AM3/20/12
to dev-secur...@lists.mozilla.org
On 20/03/12 21:28 PM, Ned Ulbricht wrote:
> On 03/19/2012 10:06 PM, ianG wrote:
>
>> The thing is, by agreeing to the policy (contract) the CA binds itself
>> to those conditions.
>
> Ummm... this assertion makes me very, very uncomfortable.

You must represent a CA then :)


> Excuse me if this has been covered already, but I've got some real
> basic, preliminary questions:
>
> * Who are the parties to this (alleged) contract?

Each listed CA and Mozilla Foundation.

> * Where and When was this (alleged) contract formed?

Location is unimportant. The contract is formed the moment that MF
accepted the application for root listing.


> * Which body of law governs this (alleged) contract?

California, although that's a first order assumption as it is not stated.

> Of course, one typical purpose behind a contract is to keep the parties
> out of court. But still, potentially:
>
> * What court are we in?

Again not stated. So assume California court, but if both parties agree
they could dispute anywhere.



(BTW, the above are all just my opinion, feel free to contrast.)



iang

Ned Ulbricht

unread,
Mar 20, 2012, 8:31:58 AM3/20/12
to dev-secur...@lists.mozilla.org
On 03/20/2012 08:09 AM, ianG wrote:
> On 20/03/12 21:28 PM, Ned Ulbricht wrote:
>> On 03/19/2012 10:06 PM, ianG wrote:
>>
>>> The thing is, by agreeing to the policy (contract) the CA binds itself
>>> to those conditions.
>>
>> Ummm... this assertion makes me very, very uncomfortable.
>
> You must represent a CA then :)

No. At present, I am appearing solely for myself and in connection with
my responsibilities to my users.

>> Excuse me if this has been covered already, but I've got some real
>> basic, preliminary questions:
>>
>> * Who are the parties to this (alleged) contract?
>
> Each listed CA and Mozilla Foundation.

Jointly, in one big contract?

>> * Where and When was this (alleged) contract formed?
>
> Location is unimportant. The contract is formed the moment that MF
> accepted the application for root listing.

Jurisdiction is important.

As is the basic existence of an agreement. Typically, if a binding
agreement has actually been formed, then it has been formed in some
definite place. To some extent --especially in the internet age--
--even in the telephone and telegram ages-- that is merely a convenient
fiction of law. But a fact-finder may look rather skeptically at an
agreement that was formed nowhere.

>> * Which body of law governs this (alleged) contract?
>
> California, although that's a first order assumption as it is not stated.
>
>> Of course, one typical purpose behind a contract is to keep the parties
>> out of court. But still, potentially:
>>
>> * What court are we in?
>
> Again not stated. So assume California court, but if both parties agree
> they could dispute anywhere.

If it's not stated anywhere, do we have any evidence of an agreement on
choice of law and forum?

ianG

unread,
Mar 20, 2012, 9:36:20 AM3/20/12
to dev-secur...@lists.mozilla.org, ne...@netscape.net
On 20/03/12 23:31 PM, Ned Ulbricht wrote:
> On 03/20/2012 08:09 AM, ianG wrote:
>> On 20/03/12 21:28 PM, Ned Ulbricht wrote:
>>> On 03/19/2012 10:06 PM, ianG wrote:
>>>
>>>> The thing is, by agreeing to the policy (contract) the CA binds itself
>>>> to those conditions.
>>>
>>> Ummm... this assertion makes me very, very uncomfortable.
>>
>> You must represent a CA then :)
>
> No. At present, I am appearing solely for myself and in connection with
> my responsibilities to my users.


OK - why then does this suggestion make you uncomfortable? Users want
Mozilla to bind the CAs into contracts, what could be wrong with that?


>>> Excuse me if this has been covered already, but I've got some real
>>> basic, preliminary questions:
>>>
>>> * Who are the parties to this (alleged) contract?
>>
>> Each listed CA and Mozilla Foundation.
>
> Jointly, in one big contract?


No, individually, in many contracts, one per listing. Each CA has one
contract with Mozilla Foundation.

>>> * Where and When was this (alleged) contract formed?
>>
>> Location is unimportant. The contract is formed the moment that MF
>> accepted the application for root listing.
>
> Jurisdiction is important.

Yes - if there is a dispute over which forum to chose, then a court
might expect to assert using classical lines such as where a contract
was formed....


> As is the basic existence of an agreement. Typically, if a binding
> agreement has actually been formed, then it has been formed in some
> definite place. To some extent --especially in the internet age--
> --even in the telephone and telegram ages-- that is merely a convenient
> fiction of law.

.... and a court might look at the place to establish jurisdiction. But
the court will quickly realise that as the two parties have not
physically met in one physical place (typically), then there isn't a
uniquely obvious place in any singular sense to rely upon. The old
concept offers very little help.

> But a fact-finder may look rather skeptically at an
> agreement that was formed nowhere.

The first question of discussion is whether an agreement was formed.
Assuming that both parties agree that an agreement was formed,the court
can then move to the question of jurisdiction. As it discovers the
place is unhelpful, it will look at other issues.


>>> * Which body of law governs this (alleged) contract?
>>
>> California, although that's a first order assumption as it is not stated.
>>
>>> Of course, one typical purpose behind a contract is to keep the parties
>>> out of court. But still, potentially:
>>>
>>> * What court are we in?
>>
>> Again not stated. So assume California court, but if both parties agree
>> they could dispute anywhere.
>
> If it's not stated anywhere, do we have any evidence of an agreement on
> choice of law and forum?


There is little agreement on choice of law or forum as far as I can see,
so it would be for the disputing parties to discuss, and if they
disagree, to petition their court(s). Courts are pretty used to this,
it's not novel.

When I say Californian law, it is a guesstimate. The party that wrote
the agreement and formed it with many players is in California, and
bases its other contracts in California. Mozilla Foundation published
one contract for all, and CAs come to it, not the other way around. MF
will prefer it and CAs might not feel it worth the fight. There are
other tactical reasons.

However courts might decide differently if there is a dispute over
jurisdiction. And, hopefully the parties will realise they should save
their money and decide upfront.



iang

Ned Ulbricht

unread,
Mar 20, 2012, 10:22:32 AM3/20/12
to dev-secur...@lists.mozilla.org
On 03/20/2012 09:36 AM, ianG wrote:
> On 20/03/12 23:31 PM, Ned Ulbricht wrote:
>> On 03/20/2012 08:09 AM, ianG wrote:
>>> On 20/03/12 21:28 PM, Ned Ulbricht wrote:
>>>> On 03/19/2012 10:06 PM, ianG wrote:
>>>>
>>>>> The thing is, by agreeing to the policy (contract) the CA binds itself
>>>>> to those conditions.
>>>>
>>>> Ummm... this assertion makes me very, very uncomfortable.
>>>
>>> You must represent a CA then :)
>>
>> No. At present, I am appearing solely for myself and in connection with
>> my responsibilities to my users.
>
>
> OK - why then does this suggestion make you uncomfortable? Users want
> Mozilla to bind the CAs into contracts, what could be wrong with that?

(First, just in case it might ever possibly become material, I should
perhaps disclose that I do operate a private, non-published certificate
authority. I do not intend to ever publish my root certificate, nor any
of the certificates chaining to it. Nor do I intend to ever participate
in Mozilla's CA program as a CA.)

Now, my users do not want Mozilla to bind CAs into contracts. Instead,
my users only have the dimmest, fuzziest notions about what a CA is,
what it does, and the relationships between UI elements and
organizations. They have no preference whatsoever on whether Mozilla
should or should not have contracts with CAs. They aren't really
competent to have a preference. If they knew enough to care, they'd ask
me for my opinion.

As far as my opinion goes, and the reason why your assertion made me so
very, very uncomfortable, is that if someone's going to go around
asserting the existence of a contract, then, imho, it ought to be a
valid, enforceable contract. With terms clear enough to keep the
parties out of court.



>> But a fact-finder may look rather skeptically at an
>> agreement that was formed nowhere.
>
> The first question of discussion is whether an agreement was formed.
> Assuming that both parties agree that an agreement was formed,the court
> can then move to the question of jurisdiction. As it discovers the
> place is unhelpful, it will look at other issues.

If a state or federal court does not have jurisdiction over both the
parties and the subject matter, then it isn't competent to give advice
on anything else.

ianG

unread,
Mar 20, 2012, 11:26:22 AM3/20/12
to dev-secur...@lists.mozilla.org
On 21/03/12 01:22 AM, Ned Ulbricht wrote:
> On 03/20/2012 09:36 AM, ianG wrote:
>> On 20/03/12 23:31 PM, Ned Ulbricht wrote:
>>> On 03/20/2012 08:09 AM, ianG wrote:
...
>> OK - why then does this suggestion make you uncomfortable? Users want
>> Mozilla to bind the CAs into contracts, what could be wrong with that?
>
> (First, just in case it might ever possibly become material, I should
> perhaps disclose that I do operate a private, non-published certificate
> authority. I do not intend to ever publish my root certificate, nor any
> of the certificates chaining to it. Nor do I intend to ever participate
> in Mozilla's CA program as a CA.)
>
> Now, my users do not want Mozilla to bind CAs into contracts. Instead,
> my users only have the dimmest, fuzziest notions about what a CA is,
> what it does, and the relationships between UI elements and
> organizations. They have no preference whatsoever on whether Mozilla
> should or should not have contracts with CAs. They aren't really
> competent to have a preference. If they knew enough to care, they'd ask
> me for my opinion.


Sure, I knew as I was writing it that "want" was not the right word but
I could not think of the appropriate customer-side term.

Perhaps, users expect their suppliers to have suitable arrangements to
keep matters in order?

> As far as my opinion goes, and the reason why your assertion made me so
> very, very uncomfortable, is that if someone's going to go around
> asserting the existence of a contract,


Whether I assert it or not makes little difference, except if the
parties decide to take the good advice you are suggesting. In the event
of a dispute, the first thing the court says is "where's the agreement?"
Then the parties dig deep and find it.

My words are forgotten by then.

> then, imho, it ought to be a
> valid, enforceable contract. With terms clear enough to keep the
> parties out of court.


Oh I see. You are not uncomfortable about the potential existence of
the contract, but legal poverty of it.

In that case *I fully agree*. I am uncomfortable about it too. But I
can only vaguely hope that when a dispute flairs up, the parties agree
to agree on these issues. If not, it will be expensive and damaging to
both.


>>> But a fact-finder may look rather skeptically at an
>>> agreement that was formed nowhere.
>>
>> The first question of discussion is whether an agreement was formed.
>> Assuming that both parties agree that an agreement was formed,the court
>> can then move to the question of jurisdiction. As it discovers the
>> place is unhelpful, it will look at other issues.
>
> If a state or federal court does not have jurisdiction over both the
> parties and the subject matter, then it isn't competent to give advice
> on anything else.


Well, like I said, cases involving disputes over jurisdiction are not
novel, they happen all the time in international trade. Quite how they
are resolved is beyond this forum, but resolved they are.

It's possibly also worth repeating that tactical matters will force the
balance: if MF wants to force the issue, it can drop a root. If a CA
wants to force the issue, it probably has to do it in Californian court.

I will say this - it really sucks badly to be in Californian court, and
CAs are going to regret it (except Verisign :)

One of the side-effects of that place is that both parties will refuse
to say anything in case it binds them further. So typically there can
be no forward progress because neither party will so much as admit there
is a legal or contract issue. This plays against both parties, and into
the hands of the lawyers. Oh joy, we have evolved ostriches that employ
nash equilibria.



iang

Kathleen Wilson

unread,
Mar 20, 2012, 8:51:36 PM3/20/12
to mozilla-dev-s...@lists.mozilla.org
On 3/16/12 2:07 PM, Kathleen Wilson wrote:
> As you all know, we have been working towards a policy for
> externally-operated subCAs that will provide a reasonable compromise
> between those who want all subCAs to be publicly disclosed and audited,
> and those who need to support externally-operated subCAs for large
> enterprise customers.
>


Thanks to all of you who have reviewed the proposal and provided
thoughtful input. I tried to incorporate the feedback so far, and to
make the requirement more clear.

Please review and comment on the updated text in item #9 of

http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html

Also, please let me know if any of the terminology is not quite correct,
or if more needs to be added (e.g. the EKUs and Name Constraints for SSL
and email certs).

Thanks,
Kathleen

Kyle Hamilton

unread,
Mar 21, 2012, 1:20:08 AM3/21/12
to Phillip Hallam-Baker, mozilla-dev-s...@lists.mozilla.org, Kathleen Wilson

On Mon, Mar 19, 2012 at 2:14 PM, Phillip Hallam-Baker <hal...@gmail.com> wrote:
> Today we have three components in the system that each think that they
> are doing the right thing. The problem is that none of the pieces
> quite join up like they should and those gaps are where the bad guys
> can take a jackhammer and tear them apart.

...which is why we need a strong CABF with payment card industry type contracts in place, to ensure that inspections find tiny cracks in the concrete early enough that they're fixed before an Iranian hacker exploits them.

Lack of contractual authority prevents inspections by auditors we've trained and certified, and we're stuck relying on audit reports by people who either don't know what they're doing or can be subverted.

-Kyle H

ArkanoiD

unread,
Mar 21, 2012, 5:07:17 AM3/21/12
to Rob Stradling, mozilla-dev-s...@lists.mozilla.org, Kathleen Wilson
If there are constraints (name, policy, KU, EKU, whatever) in a CA:true (regardless if it is root or intermediate) certificate, and there is a subordinate certificate signed by it (regarless if it is leaf or intermediate) and those constraints are not explicitly inherited "downwards", we should either treat it as inherited or (better) consider the whole chain to be broken and non-verifiable.

ianG

unread,
Mar 21, 2012, 9:57:44 AM3/21/12
to dev-secur...@lists.mozilla.org
On 21/03/12 16:20 PM, Kyle Hamilton wrote:
>
> On Mon, Mar 19, 2012 at 2:14 PM, Phillip Hallam-Baker <hal...@gmail.com>
> wrote:
>> Today we have three components in the system that each think that they
>> are doing the right thing. The problem is that none of the pieces
>> quite join up like they should and those gaps are where the bad guys
>> can take a jackhammer and tear them apart.
>
> ...which is why we need a strong CABF with payment card industry type
> contracts in place, to ensure that inspections find tiny cracks in the
> concrete early enough that they're fixed before an Iranian hacker
> exploits them.


Reminds me of this :)

http://xkcd.com/927/



> Lack of contractual authority prevents inspections by auditors we've
> trained and certified, and we're stuck relying on audit reports by
> people who either don't know what they're doing or can be subverted.

Um. That's an interesting theory ... any evidence for it?

I would suggest that it is more convoluted than that. The first part of
the puzzle is that the CA contracts the auditor, and the review criteria
are designed to their benefit. That's sort of what you are getting at
above, in that the vendor as relying party could contract the audit and
write the criteria - this is the model used in CC for example.

The second part of the puzzle is the wider change in audit integrity
over the last 20 or so years, which can perhaps be summed up with one
question:

did any auditor ring the bell on any failed/bailed firm during the last
financial crisis?

iang

Phillip Hallam-Baker

unread,
Mar 21, 2012, 10:38:07 AM3/21/12
to ianG, dev-secur...@lists.mozilla.org
One of the reasons I had been resisting turning CABForum into yet
another standards body is that I was involved in setting up W3C and
turning that into a standards body competing with IETF and then SAML
which put OASIS in competition with W3C.

But recent discussions on the PKIX list have changed my mind. The IETF
is not an organization that develops standards, it is an organization
that documents and recognizes standards.


We do have an issue to address here. From where I sit with the
information available to me I am very confident that the public SSL CA
system is basically sound. There are some structural problems (CA
shopping, race to the bottom) that CABForum and the EV/DV guidelines
are intended to address. But otherwise I am confident.

The problem is that almost nobody else is or can be. I can't even
reveal all of the information that I have. This is why I think that
the most important contribution to the recent debate is the Google
Certificate Transparency proposal. Not for the specific proposal
(which is kinda sketchy to be honest) but for introducing the concept
of transparency as distinct from audit (or maybe that is merely my
interpretation).


I really don't see strengthening the authority of institutions as the
answer as Kyle proposes. If people won't believe me, why should they
trust some organization that has its own politics and self interest?
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy



--
Website: http://hallambaker.com/

Mill Hammer

unread,
Mar 20, 2012, 11:51:45 PM3/20/12
to mozilla-dev-s...@lists.mozilla.org
> XMPP:    start...@startcom.org
I get the sense of the above and it seems on first reading to be ok,
for what it says. What it doesn't say or I am missing is what happens
with constraints not recognised above (TLS & email)?  Does this mean
that the above two key-usage constraints are the only ones permitted,
or that any other key-usage constraints can be employed without
further constraints on name spaces?
<a href="http://www.oreminingprocess.com/products/dressing/magnetic-
separation/dry-drum-magnetic.html">chrome ore separation machine</a>

Eddy Nigg

unread,
Mar 21, 2012, 5:49:49 PM3/21/12
to mozilla-dev-s...@lists.mozilla.org
On 03/21/2012 02:51 AM, From Kathleen Wilson:
> Please review and comment on the updated text in item #9 of

I noticed that the domain control requirement has been dropped and
assume that item #11 where the BR becomes a requirement covers that
aspect. I just want to confirm that this was the intention.

> Also, please let me know if any of the terminology is not quite
> correct, or if more needs to be added (e.g. the EKUs and Name
> Constraints for SSL and email certs).
>

Well, basically if a CA certificate has for example the TLS Web Server
Authentication (1.3.6.1.5.5.7.3.1) EKU, than strictly speaking it can be
used as a server certificate itself, but not as a client authentication
or code signing certificate. If no EKU was set, it can be used for
everything including as a server certificate.

Of course CA certificates shouldn't be used as server certificates
really....The meaning of those EKUs weren't meant for what you are
trying to achieve, but it might be possible to /misuse/ it as you suggested.

Otherwise you might want to invent some new OIDs which wouldn't conflict
with existing ones and could be used by Mozilla (and perhaps any other
party interested) to restrict issuance by such a CA certificate.

--
Regards

Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org

Erwann Abalea

unread,
Mar 21, 2012, 8:39:13 PM3/21/12
to mozilla-dev-s...@lists.mozilla.org
Le mercredi 21 mars 2012 22:49:49 UTC+1, Eddy Nigg a écrit :
> On 03/21/2012 02:51 AM, From Kathleen Wilson:
> > Also, please let me know if any of the terminology is not quite
> > correct, or if more needs to be added (e.g. the EKUs and Name
> > Constraints for SSL and email certs).
>
> Well, basically if a CA certificate has for example the TLS Web Server
> Authentication (1.3.6.1.5.5.7.3.1) EKU, than strictly speaking it can be
> used as a server certificate itself, but not as a client authentication
> or code signing certificate. If no EKU was set, it can be used for
> everything including as a server certificate.
>
> Of course CA certificates shouldn't be used as server certificates
> really....The meaning of those EKUs weren't meant for what you are
> trying to achieve, but it might be possible to /misuse/ it as you suggested.
>
> Otherwise you might want to invent some new OIDs which wouldn't conflict
> with existing ones and could be used by Mozilla (and perhaps any other
> party interested) to restrict issuance by such a CA certificate.

I agree with Eddy.

The extendedKeyUsage extension replaced the original netscapeCertType one, in a more flexible manner (sequence of OIDs instead of a bit mask). Using end-user OIDs for CAs isn't going to help achieving the desired goal.

In the netscapeCertType extension, there were "S/MIME CA", "SSL CA" and "ObjectSigning CA". These roles haven't been assigned a corresponding OID to be used in extendedKeyUsage. That's what is looked for here. Therefore, why can't Mozilla define new OIDs for these usages, instead of using existent ones with a different meaning?

In X.509, this would be defined like a constraint, and the extKeyUsage extension should be set critical. But with unknown OIDs (for other toolkits), the critical flag would be bad. Since NSS can be modified to recognize these new OIDs, the critical flag is not necessary anymore.

ianG

unread,
Mar 21, 2012, 8:44:32 PM3/21/12
to dev-secur...@lists.mozilla.org
Hi Phillip,


On 22/03/12 01:38 AM, Phillip Hallam-Baker wrote:
> One of the reasons I had been resisting turning CABForum into yet
> another standards body is that I was involved in setting up W3C and
> turning that into a standards body competing with IETF and then SAML
> which put OASIS in competition with W3C.
>
> But recent discussions on the PKIX list have changed my mind. The IETF
> is not an organization that develops standards, it is an organization
> that documents and recognizes standards.

With a nod to xkcd and ETSI, it could be said that EV & BR are an
americanisation of ETSI standards in this area - both the ETSI documents
were fair stabs at documenting current best practices in CAs. So there
would be a role for say IETF to bring the two of them back together.
Just a thought.

But this would still amount to fiddling while Rome burns - we don't want
to rewrite the building codes to change the thickness of wood, we want
to switch to stone instead.


> We do have an issue to address here. From where I sit with the
> information available to me I am very confident that the public SSL CA
> system is basically sound. There are some structural problems (CA
> shopping, race to the bottom) that CABForum and the EV/DV guidelines
> are intended to address. But otherwise I am confident.


I'm not sure how you come to that conclusion, but as you don't lay out
any facts it is obviously going to be hard to do anymore than follow the
leap of faith:


> The problem is that almost nobody else is or can be.

right! So the facts are as such: the academic and/or security community
has dissected and interpreted the various weaknesses in the concept of
PKI for around 2 decades now. The problems never turned up in the first
decade of PKI's operation but did turn up in around 2011, +/- some years.

The issues were all documented: contract failures, single point of
failure, the many-CAs-are-equal leap of faith, revocation myth, etc, but
we had to wait until some disaster before the science was able to speak
empirically. I won't bother to post references...


> I can't even
> reveal all of the information that I have.


The critics did, and history sided with them. You've set yourself up a
heavy burden :)


> This is why I think that
> the most important contribution to the recent debate is the Google
> Certificate Transparency proposal. Not for the specific proposal
> (which is kinda sketchy to be honest) but for introducing the concept
> of transparency as distinct from audit (or maybe that is merely my
> interpretation).


Transparency would help a lot -- but would it itself be captured by
those who are seeking to preserve their lot? Have a look at what
CABForum are doing now, asking for applications from user-interested
folks for the roles of "transparency agent". Capture? Redefine the
terms to their opposites and see if anyone notices? Give the enemies a
tiny role to distract them? Divide the innocent from the wise?
Time-honoured techniques....



(Just as a quibble on the above: I don't think audit can ever be
synonymous with Transparency, indeed they are opposites if not antonyms.
If there is transparency, there is no need for audit, it is only
needed to the extent that things aren't transparent.)


> I really don't see strengthening the authority of institutions as the
> answer as Kyle proposes. If people won't believe me, why should they
> trust some organization that has its own politics and self interest?


In that we agree. I think we've had enough evidence to suggest that one
more institution is not going to help. Indeed, the period of CABForum's
history is marked with lost opportunity. Can we really improve that by
giving them more powers?

The problem with this is the same old: "someone must do something!"

When we already know we got into this mess because we said that the last
10 times.



iang

Eddy Nigg

unread,
Mar 21, 2012, 8:55:46 PM3/21/12
to mozilla-dev-s...@lists.mozilla.org
On 03/22/2012 02:39 AM, From Erwann Abalea:
> In the netscapeCertType extension, there were "S/MIME CA", "SSL CA" and "ObjectSigning CA". These roles haven't been assigned a corresponding OID to be used in extendedKeyUsage. That's what is looked for here.

Yes, perhaps it can be hooked into 1.3.6.1.5.5.7.<CA-purpose>.<Purpose>
- probably a job for Gerv ;-)

Rob Stradling

unread,
Mar 22, 2012, 4:19:41 AM3/22/12
to Erwann Abalea, Kathleen Wilson, mozilla-dev-s...@lists.mozilla.org
On 22/03/12 00:39, Erwann Abalea wrote:
<snip>
> The extendedKeyUsage extension replaced the original netscapeCertType one, in a more flexible manner (sequence of OIDs instead of a bit mask). Using end-user OIDs for CAs isn't going to help achieving the desired goal.
>
> In the netscapeCertType extension, there were "S/MIME CA", "SSL CA" and "ObjectSigning CA".

Given that NSS still supports the netscapeCertType extension, and given
that this extension already supports the required semantics, I think the
best way to achieve what Kathleen wants to do would be to "un-deprecate"
netscapCertType and require it to be present (with the "S/MIME CA", "SSL
CA" and/or "ObjectSigning CA" bits set as appropriate) for
externally-operated Sub-CAs.

I've just been bitten by a recent change in how NSS treats the EKU
extension in CA certificates [1]. I'm pretty sure (based on experience
diagnosing [1]) that if a CA certificate were (as you and Eddy are
proposing) to contain the EKU extension with _only_ a new OID meaning
"SSL Server CA", all versions of NSS would _reject_ it as a valid issuer
of SSL Server Certificates!

So using netscapeCertType would be safer than using the EKU extension,
because zero code changes would be required. Let's not risk breaking
backwards compatibility unless we have to, and let's not write new code
when the old code works just fine.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=737802

> These roles haven't been assigned a corresponding OID to be used in extendedKeyUsage. That's what is looked for here. Therefore, why can't Mozilla define new OIDs for these usages, instead of using existent ones with a different meaning?
>
> In X.509, this would be defined like a constraint, and the extKeyUsage extension should be set critical. But with unknown OIDs (for other toolkits), the critical flag would be bad. Since NSS can be modified to recognize these new OIDs, the critical flag is not necessary anymore.
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

--

Erwann Abalea

unread,
Mar 22, 2012, 7:43:16 AM3/22/12
to mozilla-dev-s...@lists.mozilla.org
Le jeudi 22 mars 2012 09:19:41 UTC+1, Rob Stradling a écrit :
> On 22/03/12 00:39, Erwann Abalea wrote:
> <snip>
> > The extendedKeyUsage extension replaced the original netscapeCertType one, in a more flexible manner (sequence of OIDs instead of a bit mask). Using end-user OIDs for CAs isn't going to help achieving the desired goal.
> >
> > In the netscapeCertType extension, there were "S/MIME CA", "SSL CA" and "ObjectSigning CA".
>
> Given that NSS still supports the netscapeCertType extension, and given
> that this extension already supports the required semantics, I think the
> best way to achieve what Kathleen wants to do would be to "un-deprecate"
> netscapCertType and require it to be present (with the "S/MIME CA", "SSL
> CA" and/or "ObjectSigning CA" bits set as appropriate) for
> externally-operated Sub-CAs.

I'm "sliced" with un-deprecating a thing. It is deprecated because EKU has been defined to reach the same goal in a better way. Won't "require it (nsCertType) to be present" break existing things?

> I've just been bitten by a recent change in how NSS treats the EKU
> extension in CA certificates [1]. I'm pretty sure (based on experience
> diagnosing [1]) that if a CA certificate were (as you and Eddy are
> proposing) to contain the EKU extension with _only_ a new OID meaning
> "SSL Server CA", all versions of NSS would _reject_ it as a valid issuer
> of SSL Server Certificates!

I read the bug (and referenced others). That's informative, thanks. libPKIX is not dry yet.

> So using netscapeCertType would be safer than using the EKU extension,
> because zero code changes would be required. Let's not risk breaking
> backwards compatibility unless we have to, and let's not write new code
> when the old code works just fine.

Again, I'm still not satisfied by this solution (reuse an old deprecated extension). But I'm not satisfied either by libPKIX failures with step-up only EKU in CA certs.

Phillip Hallam-Baker

unread,
Mar 22, 2012, 8:18:03 AM3/22/12
to Erwann Abalea, mozilla-dev-s...@lists.mozilla.org
The question is what constraints are implemented rather than what is pretty.

Thinking back to how we might have got into this mess I am pretty sure
that the cross-over from the client cert world to the SSL one is where
the problem likely slipped in.

There are really good reasons why an enterprise would want to have
local control of their client sub-CA key that do not apply to server
certs.


On Thu, Mar 22, 2012 at 7:43 AM, Erwann Abalea <eab...@gmail.com> wrote:
> Le jeudi 22 mars 2012 09:19:41 UTC+1, Rob Stradling a écrit :
>> On 22/03/12 00:39, Erwann Abalea wrote:
>> <snip>
>> > The extendedKeyUsage extension replaced the original netscapeCertType one, in a more flexible manner (sequence of OIDs instead of a bit mask). Using end-user OIDs for CAs isn't going to help achieving the desired goal.
>> >
>> > In the netscapeCertType extension, there were "S/MIME CA", "SSL CA" and "ObjectSigning CA".
>>
>> Given that NSS still supports the netscapeCertType extension, and given
>> that this extension already supports the required semantics, I think the
>> best way to achieve what Kathleen wants to do would be to "un-deprecate"
>> netscapCertType and require it to be present (with the "S/MIME CA", "SSL
>> CA" and/or "ObjectSigning CA" bits set as appropriate) for
>> externally-operated Sub-CAs.
>
> I'm "sliced" with un-deprecating a thing. It is deprecated because EKU has been defined to reach the same goal in a better way. Won't "require it (nsCertType) to be present" break existing things?
>
>> I've just been bitten by a recent change in how NSS treats the EKU
>> extension in CA certificates [1].  I'm pretty sure (based on experience
>> diagnosing [1]) that if a CA certificate were (as you and Eddy are
>> proposing) to contain the EKU extension with _only_ a new OID meaning
>> "SSL Server CA", all versions of NSS would _reject_ it as a valid issuer
>> of SSL Server Certificates!
>
> I read the bug (and referenced others). That's informative, thanks. libPKIX is not dry yet.
>
>> So using netscapeCertType would be safer than using the EKU extension,
>> because zero code changes would be required.  Let's not risk breaking
>> backwards compatibility unless we have to, and let's not write new code
>> when the old code works just fine.
>
> Again, I'm still not satisfied by this solution (reuse an old deprecated extension). But I'm not satisfied either by libPKIX failures with step-up only EKU in CA certs.
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy



--
Website: http://hallambaker.com/

Rob Stradling

unread,
Mar 22, 2012, 8:34:36 AM3/22/12
to Erwann Abalea, mozilla-dev-s...@lists.mozilla.org
On 22/03/12 11:43, Erwann Abalea wrote:
> Le jeudi 22 mars 2012 09:19:41 UTC+1, Rob Stradling a écrit :
>> On 22/03/12 00:39, Erwann Abalea wrote:
>> <snip>
>>> The extendedKeyUsage extension replaced the original netscapeCertType one, in a more flexible manner (sequence of OIDs instead of a bit mask). Using end-user OIDs for CAs isn't going to help achieving the desired goal.
>>>
>>> In the netscapeCertType extension, there were "S/MIME CA", "SSL CA" and "ObjectSigning CA".
>>
>> Given that NSS still supports the netscapeCertType extension, and given
>> that this extension already supports the required semantics, I think the
>> best way to achieve what Kathleen wants to do would be to "un-deprecate"
>> netscapCertType and require it to be present (with the "S/MIME CA", "SSL
>> CA" and/or "ObjectSigning CA" bits set as appropriate) for
>> externally-operated Sub-CAs.
>
> I'm "sliced" with un-deprecating a thing. It is deprecated because EKU has been defined to reach the same goal in a better way.

The use of EKU in CA certificates has _not_ been adequately defined!!

What does it mean to put (or not put!) the "Server Authentication" EKU
OID into a CA Certificate?
Opinions and implementations differ. RFC5280 offers little guidance.

What does it mean to put the "SSL CA" netscapeCertType into a CA
Certificate?
Opinions and implementations _do not_ differ, AFAIK.

> Won't "require it (nsCertType) to be present" break existing things?

As Kathleen has clarified, "require it...to be present" in
externally-operated CA Certificates will be a policy requirement. It
will _not_ be enforced in code, because the code will have no way to
distinguish between externally-operated and internally-operated CAs.

<snip>

Carsten.D...@t-systems.com

unread,
Mar 22, 2012, 1:35:09 PM3/22/12
to kwi...@mozilla.com, mozilla-dev-s...@lists.mozilla.org
Hi Kathleen, All,

sorry for the delayed response on this matter - it took some time to get all the information needed. I'm afraid, this will become nearly as long as your original post.

I would like to raise and discuss an issue we (T-Systems International GmbH) are facing with the current proposal. The only accepted implementation for "technically constrained" will be appropriate Name Constraints (rfc822Name / dNSName) within the Sub-CA certificate.

As far as we understand, the main goal of the proposal is to ensure by _technical_ constraints (not by contract), that Enterprise Sub-CAs are not able to issue certificates for domains/servers (in case of SSL/TLS) they do not legitimately own or control.

That said, please let me explain the scenario under which one of our customers is running its Sub-CA.

T-Systems issued a Enterprise Sub-CA to Europe's largest applied research organization "Fraunhofer Gesellschaft" (Fraunhofer Society). Fraunhofer is comprised of 60 institutes currently, mainly located in Germany and employs more than 18.000 people, basically scientists and engineers. Fraunhofer's business is mainly applied research in various areas and thus it runs a lot of projects in these areas. Projects are often run in cooperation with universities or commercial enterprises, as well as governmental authorities. For example the MP3 compression algorithm was invented and patented by one of Fraunhofer's institutes.

As a consequence of its size and the broad research areas covered, Fraunhofer currently has registered MORE THAN 2500 domains! Most of them dedicated for the appropriate projects.

Apart from the number of domains (I doubt but don't know for sure whether it would be possible to include more than 2500 domains as Name Constraint within a certificate) the way Fraunhofer is operating makes it impossible to use Name Constraints. New domains are constantly added as new projects get started, which would require to re-issue the Sub-CA certificate almost every month.

That said, we strongly believe that there are excellent technical controls in place to ensure certificates are issued for owned/controlled domains only. Each employee is provided with a personalized smartcard. Requests for certificates require the ownership of this smartcard (and its PIN obviously). Certificates can be requested for white listed domains only, i.e. the domain needs to be included in a directory maintained by Fraunhofer's NOC, which is separate from the PKI infrastructure. Only employees assigned the role named "IT Manager" are able to approve the inclusion of a new domain within the list. There are only a few employees assigned with this role. And last but not least, certificate requests are manually processed.

If you are interested in more detailed information you may have a look at the German (http://de.wikipedia.org/wiki/Fraunhofer-Gesellschaft) and English Wikipedia entries (http://en.wikipedia.org/wiki/Fraunhofer_Society) as well as the official websites http://www.fraunhofer.org/ and http://www.fraunhofer.de/.

We do not see any chance for us to run this Enterprise Sub-CA under the proposed requirements, although there are strong technical controls in place which we believe to be more than sufficient.

One may argue, that Fraunhofer should undergo an appropriate e.g. WebTrust or ETSI audit. My concern would be, that there is no benefit for the customer to operate as Sub-CA any longer. IMHO it would be a logical step to apply for a root inclusion for themselves, which would blow up the list of embedded roots further more. A common shared point of view (on this list and in other forums as well) seems to be that the number of trusted roots should be decreased, not expanded.

Sharing your thoughts on this is really appreciated.

Kind regards,
Carsten

Carsten Dahlenkamp
T-Systems International GmbH
Trust Center Applications
Untere Industriestraße 20, 57250 Netphen, Germany
+49 271 708-1643 (Tel.)
E-Mail: carsten.d...@t-systems.com
http://www.t-systems.com, http://www.telesec.de

-----Original Message-----
From: dev-security-policy-bounces+carsten.dahlenkamp=t-
syste...@lists.mozilla.org [mailto:dev-security-policy-
bounces+carsten.dahlenkamp=t-syst...@lists.mozilla.org] On Behalf Of
Kathleen Wilson
Sent: Friday, March 16, 2012 10:08 PM
To: mozilla-dev-s...@lists.mozilla.org
Subject: New Proposed policy for Externally-Operated subCAs

This is long, so please bear with me and read all the way through before
passing judgement.

As you all know, we have been working towards a policy for
externally-operated subCAs that will provide a reasonable compromise
between those who want all subCAs to be publicly disclosed and audited,
and those who need to support externally-operated subCAs for large
enterprise customers.

I have been looking for ways that an externally-operated subCA
certificate can be technically constrained that will satisfy those who
are demanding auditing and disclosure of all subCAs. It appears that the
only way to accomplish this will be for an extension/constraint to be
specified in the intermediate certificate and controlled by crypto code
(e.g. NSS for Mozilla). I believe there are two ways that an
externally-operated subordinate CA certificate will need to be
constrained. First, the key usage of the certificates that the
externally-operated certificate signs must be controlled. Second,
externally-operated subCA certificates that can sign SSL and S/MIME
certificates need to include name constraints.

In regards to limiting the key usage of certificates signed by an
externally-operated subordinate CA certificate, I believe there are two
potential ways that this could be done. One way would be to standardize
on a set of Policy OIDs for things like SSL and S/MIME. However, I think
this would be difficult to achieve, and if this were a viable option,
then I think that there would have been a standard EV Policy OID. The
other way is to use Extended Key Usage (EKU).

The proposal is that the EKU would be specified in the intermediate
certificates, and the crypto code would look up the certificate chain at
the EKU extensions to make sure that the end-entity certificate is
allowed to be used for that purpose. The old NSS code does this if the
EKU extension is present in the intermediate certificate, but the new
libpkix code doesn't currently do this. Ryan Hurst has filed a bug
requesting that this behavior be added to libpkix:
https://bugzilla.mozilla.org/show_bug.cgi?id=725351

I understand that RFC 5280 does not require the EKUs be consistent
through the certificate hierarchy. However, I have been unable to find
another viable solution to restricting the key usage of certificates
issued by externally-operated subCAs.

I propose that we consider using EKU in this way and requiring it in
Mozilla's CA Certificate Policy for externally-operated subordinate CAs.
If we agree to go in this direction, then I believe it would be fine to
first add the requirement to Mozilla's CA Certificate Policy, and then
follow with updating the code in NSS libpkix to enforce it.

I would like to submit the following text for consideration to replace
the currently proposed text in #9 of
http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/Inc
lusionPolicy.html

--
9. Each externally-operated subordinate CA must either be audited in
accordance with Mozilla's CA Certificate Policy or must be technically
constrained.

- Each externally-operated subordinate CA that is not technically
constrained must be publicly disclosed, along with the subordinate CA's
corresponding Certificate Policy or Certification Practice Statement and
public attestation of the subordinate CA's conformance to the stated
certificate verification requirements and other operational criteria by
a competent independent party or parties with access to details of the
subordinate CA's internal operations. The subordinate CA's certificate
verification requirements and operational criteria must satisfy the
requirements of Mozilla's CA Certificate Policy. The CA's Certificate
Policy or Certification Practice Statement must indicate where the list
of publicly disclosed subordinate CAs may be found on the CA's website.

- For an externally-operated subordinate CA to be considered technically
constrained, the subordinate CA certificate (and any intermediate
certificates chaining up to that certificate) must include an Extended
Key Usage (EKU) extension specifying the key usage of the certificates
it can sign.

-- If the EKU includes "TLS WWW server authentication" then the
certificate must also include X.509 dNSName Name Constraints as
specified in RFC 5280, and the Name Constraints must only include
domains for which the CA has confirmed that the subordinate CA has
registered or has been authorized by the domain registrant to act on the
registrant's behalf.

-- If the EKU includes "Email protection" then the certificate must also
include rfc822Name Name Constraints as specified in RFC 5280, and the
Name Constraints must only include email addresses or mailboxes for
which the CA has confirmed that the subordinate CA is authorized to use.

-- The CA must also have additional technical and/or contractual
restrictions in place to ensure that the subordinate CA fully complies
with Mozilla's CA Certificate Policy. Such controls must be documented
in the CA's Certificate Policy or Certification Practice Statement, and
reviewed by a competent independent party as part of the CA's annual
audit.

-- Alternate methods of technical controls must be publicly reviewed and
approved, according to Mozilla's process that begins with submitting a
bug report into the mozilla.org Bugzilla system, filed against the "CA
Certificates" component of the "mozilla.org" product. Mozilla's wiki
page, <page link>, provides further details about how to submit a formal
request.
--


If this (or some version of this) new text gains acceptance, then we
will discuss the timeline for when the new policy updates would be
enforced. For example, the new policy would apply to all new
externally-operated subCA certificates, and all old externally-operated
subCA certificates would need to be updated by <some reasonable date>.

I will greatly appreciate your thoughtful and constructive input into
this proposal.

Kathleen

Erwann Abalea

unread,
Mar 22, 2012, 2:58:47 PM3/22/12
to mozilla-dev-s...@lists.mozilla.org
Bonsoir,

Le jeudi 22 mars 2012 18:35:09 UTC+1, Carsten.D...@t-systems.com a écrit :
[...]
> Apart from the number of domains (I doubt but don't know for sure whether it would be possible to include more than 2500 domains as Name Constraint within a certificate) the way Fraunhofer is operating makes it impossible to use Name Constraints. New domains are constantly added as new projects get started, which would require to re-issue the Sub-CA certificate almost every month.

It is technically possible to include 2500 domains in the nameConstraints extension. It just couldn't be transmitted as part of the TLS handshake because of implementation limits (TLS records are 16k max, some implementations don't support TLS messages to span several records).

Thanks for this information, it means the proposed solution cannot apply to everybody.

Rob Stradling

unread,
Mar 22, 2012, 4:09:43 PM3/22/12
to Carsten.D...@t-systems.com, mozilla-dev-s...@lists.mozilla.org, kwi...@mozilla.com
On 22/03/12 17:35, Carsten.D...@t-systems.com wrote:
<snip>
> As far as we understand, the main goal of the proposal is to ensure by _technical_ constraints (not by contract)...

Hi Carsten. Did you consider this part...

"Each externally-operated subordinate CA that is not technically
constrained must be publicly disclosed, along with the subordinate CA's
corresponding Certificate Policy or Certification Practice Statement and
public attestation of the subordinate CA's conformance to the stated
certificate verification requirements and other operational criteria by
a competent independent party or parties with access to details of the
subordinate CA's internal operations. The subordinate CA's certificate
verification requirements and operational criteria must satisfy the
requirements of Mozilla's CA Certificate Policy. The CA's Certificate
Policy or Certification Practice Statement must indicate where the list
of publicly disclosed subordinate CAs may be found on the CA's website." [1]

> One may argue, that Fraunhofer should undergo an appropriate e.g.
> WebTrust or ETSI audit.

I'm not clear if "public attestation...by a competent independent
party..." necessarily means anything as involved as a WebTrust or ETSI
audit. (I try to keep well clear of the audit side of things and stick
to writing code!)

[1]
http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html
(section 9)

Eddy Nigg

unread,
Mar 22, 2012, 4:28:48 PM3/22/12
to mozilla-dev-s...@lists.mozilla.org
On 03/22/2012 10:09 PM, From Rob Stradling:
> I'm not clear if "public attestation...by a competent independent
> party..." necessarily means anything as involved as a WebTrust or ETSI
> audit.

Though it might become one, some discussions are happening in parallel
and what happens here may influence the CAB Forum discussions and vice
versa. Eventually I believe any CA will be either audited by the same
audit requirements as all CAs must be or under constraints of the parent
CA, e.g. non-external.

Kathleen Wilson

unread,
Mar 22, 2012, 5:16:13 PM3/22/12
to mozilla-dev-s...@lists.mozilla.org
On 3/22/12 1:28 PM, Eddy Nigg wrote:
> On 03/22/2012 10:09 PM, From Rob Stradling:
>> I'm not clear if "public attestation...by a competent independent
>> party..." necessarily means anything as involved as a WebTrust or ETSI
>> audit.
>
> Though it might become one, some discussions are happening in parallel
> and what happens here may influence the CAB Forum discussions and vice
> versa. Eventually I believe any CA will be either audited by the same
> audit requirements as all CAs must be or under constraints of the parent
> CA, e.g. non-external.
>


Yes, that is the intent of the proposed requirement. If it's not clear
that the audit of non-constrained externally-operated subCAs needs to be
done in accordance with Mozilla's CA Certificate Policy and be done
according to WebTrust or ETSI criteria, then I need to work on that text
some more. Should I add another sentence to that effect?


Carsten, Thank you for providing this example of a large enterprise
customer. While many CAs have eluded to this sort of customer, you are
the first (that I know of) to provide an actual real-life situation in
the discussion forum that we can consider as a use case of the new
proposed requirement.


So the question is: Is the new requirement reasonable for the enterprise
customers who have a very large number of domains that they issue
certificates for?

Such customers would have a few options:
a) Have an unconstrained intermediate certificate and be audited
according to the appropriate WebTrust or ETSI criteria.
b) Have many technically-constrained intermediate certificates
c) Use a managed-service, in which the CA operates the subCA's
intermediate certificates (and related systems), and provides a user
interface for the customer to issue certificates.
d) Other???


On the other hand, is the technical solution that Carsten outlined
sufficient for large externally-operated subCA enterprise customers?
"Each employee is provided with a personalized smartcard. Requests for
certificates require the ownership of this smartcard (and its PIN
obviously). Certificates can be requested for white listed domains only,
i.e. the domain needs to be included in a directory maintained by
Fraunhofer's NOC, which is separate from the PKI infrastructure. Only
employees assigned the role named "IT Manager" are able to approve the
inclusion of a new domain within the list. There are only a few
employees assigned with this role. And last but not least, certificate
requests are manually processed."

If that sort of solution is sufficient for certain types of
externally-operated subCA customers, then how do we include allowance
for this in Mozilla's CA Certificate Policy, while still constraining
all of the other (smaller) externally-operated subCAs?

Thanks,
Kathleen







Eddy Nigg

unread,
Mar 22, 2012, 5:42:15 PM3/22/12
to mozilla-dev-s...@lists.mozilla.org
On 03/22/2012 11:16 PM, From Kathleen Wilson:
> On the other hand, is the technical solution that Carsten outlined
> sufficient for large externally-operated subCA enterprise customers?
> "Each employee is provided with a personalized smartcard. Requests for
> certificates require the ownership of this smartcard (and its PIN
> obviously). Certificates can be requested for white listed domains
> only, i.e. the domain needs to be included in a directory maintained
> by Fraunhofer's NOC, which is separate from the PKI infrastructure.
> Only employees assigned the role named "IT Manager" are able to
> approve the inclusion of a new domain within the list. There are only
> a few employees assigned with this role. And last but not least,
> certificate requests are manually processed."

This is what the requirements will call for anyway, but it will have to
be audited - that's the main difference. All CAs will have to be
compliant to the requirements (currently assuming BR 1.0, maybe soon BR
1.1 which will have some more teeth).

> If that sort of solution is sufficient for certain types of
> externally-operated subCA customers, then how do we include allowance
> for this in Mozilla's CA Certificate Policy, while still constraining
> all of the other (smaller) externally-operated subCAs?

Clearly not, I don't believe this was the intention. When looking ahead
down the road, what's outlined above will be required in any case, which
makes it clear that this isn't the solution most are seeking with these
new requirement (that your proposed in this thread), it's just part of
much more.

ianG

unread,
Mar 23, 2012, 11:42:30 AM3/23/12
to dev-secur...@lists.mozilla.org
On 23/03/12 08:16 AM, Kathleen Wilson wrote:
> On 3/22/12 1:28 PM, Eddy Nigg wrote:
>> On 03/22/2012 10:09 PM, From Rob Stradling:
>>> I'm not clear if "public attestation...by a competent independent
>>> party..." necessarily means anything as involved as a WebTrust or ETSI
>>> audit.
>>
>> Though it might become one, some discussions are happening in parallel
>> and what happens here may influence the CAB Forum discussions and vice
>> versa. Eventually I believe any CA will be either audited by the same
>> audit requirements as all CAs must be or under constraints of the parent
>> CA, e.g. non-external.
>>
>
>
> Yes, that is the intent of the proposed requirement. If it's not clear
> that the audit of non-constrained externally-operated subCAs needs to be
> done in accordance with Mozilla's CA Certificate Policy and be done
> according to WebTrust or ETSI criteria, then I need to work on that text
> some more. Should I add another sentence to that effect?


If the parent CA is taking full responsibility, and their audit covers
the sub-CA, it matter not two hoots whether it is internal, external, on
the moon, or distributed across the iphones of the employees. The
auditor is fully capable - he's an expert in this - in determining
whether a sub-CA is ok or not. All that has to be done is the CA
employs the auditor and in the engagement letter, the sub-CA(s) are
declared "in scope." Done deal. End of story.

Please: the reason we have trouble with sub-CAs is because the auditor
doesn't audit them and the company pretends it isn't their problem. All
we have to do is tell the auditor to audit them. And the CA to take
*full responsibility* for them. No more slithering behind the emperor's
clothing of "separate business".

The publication of the sub-CA is a sweetener. It enables the public to
also monitor, and it creates a disclosure in advance that the CA is
taking responsibility for that sub-CA. I think this is very good for
establishing the terms that are to be stated. But disclosure itself
isn't the terms. The terms should be: responsibility by CA and by auditor.


> Carsten, Thank you for providing this example of a large enterprise
> customer. While many CAs have eluded to this sort of customer, you are
> the first (that I know of) to provide an actual real-life situation in
> the discussion forum that we can consider as a use case of the new
> proposed requirement.

Yes, +1, very useful!


> So the question is: Is the new requirement reasonable for the enterprise
> customers who have a very large number of domains that they issue
> certificates for?
>
> Such customers would have a few options:
> a) Have an unconstrained intermediate certificate and be audited
> according to the appropriate WebTrust or ETSI criteria.
> b) Have many technically-constrained intermediate certificates
> c) Use a managed-service, in which the CA operates the subCA's
> intermediate certificates (and related systems), and provides a user
> interface for the customer to issue certificates.
> d) Other???


d) Have an unconstrained intermediate certificate and be audited within
scope of the parent's audit. This might involve an internal audit done
by CA over sub-CA which is relied upon by auditor.

This could be published, as per above.


> On the other hand, is the technical solution that Carsten outlined
> sufficient for large externally-operated subCA enterprise customers?
> "Each employee is provided with a personalized smartcard. Requests for
> certificates require the ownership of this smartcard (and its PIN
> obviously). Certificates can be requested for white listed domains only,
> i.e. the domain needs to be included in a directory maintained by
> Fraunhofer's NOC, which is separate from the PKI infrastructure. Only
> employees assigned the role named "IT Manager" are able to approve the
> inclusion of a new domain within the list. There are only a few
> employees assigned with this role. And last but not least, certificate
> requests are manually processed."
>
> If that sort of solution is sufficient for certain types of
> externally-operated subCA customers, then how do we include allowance
> for this in Mozilla's CA Certificate Policy, while still constraining
> all of the other (smaller) externally-operated subCAs?


Well, here's the thing. That above sounds fine as far as it goes. But
it sort of crosses the line from policy to CPS. The challenge for the
policy is to stay high level, and place the details into CPS / audit
criteria.

Otherwise we end up rewriting & micromanaging. And although that
theoretically is a good idea, nobody wants to throw away BR and start again.



iang

Carsten.D...@t-systems.com

unread,
Mar 23, 2012, 1:39:40 PM3/23/12
to eddy...@startcom.org, kwi...@mozilla.com, mozilla-dev-s...@lists.mozilla.org
Hi Kathleen, Eddy,

Don't wonder, I'm replying to Kathleen's and Eddy's answer in a single mail,


[snip]
>> Such customers would have a few options:
[...]
>> b) Have many technically-constrained intermediate certificates

This is still a static thing, not offering the possibility to _add_ new domains when they are registered (nearly monthly for new projects), nor to _delete_ (when a spin-off company is founded out of a project).



[snip]
> This is what the requirements will call for anyway, but it will have
> to be audited - that's the main difference. All CAs will have to be
> compliant to the requirements (currently assuming BR 1.0, maybe soon
> BR 1.1 which will have some more teeth).

Just for clarification:
Maybe I should have added that T-Systems is auditing the Fraunhofer Sub-CA annually. This of course includes the technical controls in place to prevent the issuance of certificates for domains they do not own/control. This is our practice for a couple of years now and would meet the requirements of the BR as well as Mozilla's current CA policy. But not the new proposal.



Regards

Eddy Nigg

unread,
Mar 23, 2012, 2:58:35 PM3/23/12
to mozilla-dev-s...@lists.mozilla.org
On 03/23/2012 07:39 PM, From Carsten.D...@t-systems.com:
> This is still a static thing, not offering the possibility to _add_
> new domains when they are registered (nearly monthly for new
> projects), nor to _delete_ (when a spin-off company is founded out of
> a project). [snip]

Yes, this is not really useful in your case, it's useful for example for
enterprise CAs where there are only few domain names to consider.

> Just for clarification:
> Maybe I should have added that T-Systems is auditing the Fraunhofer Sub-CA annually. This of course includes the technical controls in place to prevent the issuance of certificates for domains they do not own/control.

A technical constraint is something that prevents issuance of
certificates for example. Or keep control of the keys and software at
the parent CA.

A self-audit is a good thing, but probably not what's requested here.
I believe auditing the CA makes complete sense in your case and there
are many benefits for them to have/keep their current arrangement with
your CA in place (addressing your previous concern). Root inclusions
with software vendors take a lot of time and effort and will cover only
systems and browsers that are released after the inclusion usually.

Kathleen Wilson

unread,
Mar 26, 2012, 2:16:59 PM3/26/12
to mozilla-dev-s...@lists.mozilla.org
On 3/23/12 8:42 AM, ianG wrote:
>> So the question is: Is the new requirement reasonable for the enterprise
>> customers who have a very large number of domains that they issue
>> certificates for?
>>
>> Such customers would have a few options:
>> a) Have an unconstrained intermediate certificate and be audited
>> according to the appropriate WebTrust or ETSI criteria.
>> b) Have many technically-constrained intermediate certificates
>> c) Use a managed-service, in which the CA operates the subCA's
>> intermediate certificates (and related systems), and provides a user
>> interface for the customer to issue certificates.
>> d) Other???
>
>
> d) Have an unconstrained intermediate certificate and be audited within
> scope of the parent's audit. This might involve an internal audit done
> by CA over sub-CA which is relied upon by auditor.
>
> This could be published, as per above.
>
>


So to comply with the proposed requirement, the options that are
available to very large enterprise customers with a large number of
domains are:

a) Have an unconstrained intermediate certificate and be publicly
disclosed and audited by a competent independent party according to
Mozilla’s CA Certificate Policy.

b) Have an unconstrained intermediate certificate and be publicly
disclosed and audited within scope of the parent CA’s audit. The auditor
may rely on an audit of the subCA that is performed by the CA.

c) Have many technically-constrained intermediate certificates.

d) Use a managed-service, in which the CA operates the subCA's
intermediate certificates (and related systems), and provides a user
interface for the customer to issue certificates.


Correct?

Kathleen

ianG

unread,
Mar 26, 2012, 8:50:32 PM3/26/12
to dev-secur...@lists.mozilla.org
On 27/03/12 05:16 AM, Kathleen Wilson wrote:
> On 3/23/12 8:42 AM, ianG wrote:
>>> So the question is: Is the new requirement reasonable for the enterprise
>>> customers who have a very large number of domains that they issue
>>> certificates for?
>>>
>>> Such customers would have a few options:
>>> a) Have an unconstrained intermediate certificate and be audited
>>> according to the appropriate WebTrust or ETSI criteria.
>>> b) Have many technically-constrained intermediate certificates
>>> c) Use a managed-service, in which the CA operates the subCA's
>>> intermediate certificates (and related systems), and provides a user
>>> interface for the customer to issue certificates.
>>> d) Other???
>>
>>
>> d) Have an unconstrained intermediate certificate and be audited within
>> scope of the parent's audit. This might involve an internal audit done
>> by CA over sub-CA which is relied upon by auditor.
>>
>> This could be published, as per above.
>>
>>
>
>
> So to comply with the proposed requirement, the options that are
> available to very large enterprise customers with a large number of
> domains are:
>
> a) Have an unconstrained intermediate certificate and be publicly
> disclosed and audited by a competent independent party according to
> Mozilla’s CA Certificate Policy.
>
> b) Have an unconstrained intermediate certificate and be publicly
> disclosed and audited within scope of the parent CA’s audit. The auditor
> may rely on an audit of the subCA that is performed by the CA.
>
> c) Have many technically-constrained intermediate certificates.
>
> d) Use a managed-service, in which the CA operates the subCA's
> intermediate certificates (and related systems), and provides a user
> interface for the customer to issue certificates.
>
>
> Correct?


Yes, b) was what I was trying to say.

In terms of that hot-button issue disclosure, I think a) has to include
disclosure, by the nature of the independent audit. For b) it is
optional but I would err on the side of disclosure.

c) and d) are within audit scope but escape disclosure. I guess that is
a reasonable compromise for now.



iang

Kathleen Wilson

unread,
Mar 27, 2012, 12:46:40 PM3/27/12
to mozilla-dev-s...@lists.mozilla.org
I'm still trying to work through this...

The currently proposed text has:
"Each externally-operated subordinate CA that is not technically
constrained must be publicly disclosed, along with the subordinate CA's
corresponding Certificate Policy or Certification Practice Statement and
public attestation of the subordinate CA's conformance to the stated
certificate verification requirements and other operational criteria by
a competent independent party or parties with access to details of the
subordinate CA's internal operations."

I think that this part:

"by a competent independent party or parties with access to details of
the subordinate CA's internal operations."

means that the unconstrained subCA has to be audited by someone other
than the CA.

So I think that this option doesn't meet the currently proposed
requirement, because of the second sentence:
> b) Have an unconstrained intermediate certificate and be publicly
> disclosed and audited within scope of the parent CA’s audit. The
> auditor may rely on an audit of the subCA that is performed by the CA.


While it is true that the unconstrained intermediate certificate could
be audited within the scope of the parent CA's audit. I don't think it's
true that the auditor may rely on an audit of the subCA that is
performed by the CA.

Maybe I'm missing something?

Kathleen





Eddy Nigg

unread,
Mar 27, 2012, 12:53:59 PM3/27/12
to mozilla-dev-s...@lists.mozilla.org
On 03/27/2012 06:46 PM, From Kathleen Wilson:
> While it is true that the unconstrained intermediate certificate could
> be audited within the scope of the parent CA's audit. I don't think
> it's true that the auditor may rely on an audit of the subCA that is
> performed by the CA.

Right - the audit may be perhaps performed by the same auditor, but
should be an independent audit. The audit statement for an externally
operated CA should be addressed to that party and not the parent CA.

Ben Bucksch

unread,
Mar 27, 2012, 1:38:44 PM3/27/12
to mozilla-dev-s...@lists.mozilla.org
First: Thanks, Kathleen for taking our concerns seriously.

On 16.03.2012 22:07, Kathleen Wilson wrote:
> 9. Each externally-operated subordinate CA must either be audited in
> accordance with Mozilla’s CA Certificate Policy or must be technically
> constrained.

One key change: "audited and approved"

If we don't approve subCAs, that basically means that our whole approval
process is meaningless and a new CA can just get a signature from any
other existing CA and avoid our process.

One concrete example: The requirement to be audited doesn't help with
rogue subCA issued to governments (or any other organization). The gov
can just get an audit and when it comes out that Iran, China, USA or
whoever *did* get a subCA and *did* use it to hunt and kill people, the
CA wasn't actually in violation with the above requirement.

> -- If the EKU includes "TLS WWW server authentication" then the
> certificate must also include X.509 dNSName Name Constraints as
> specified in RFC 5280
> -- If the EKU includes "Email protection" then the certificate must
> also include rfc822Name Name Constraints as specified in RFC 5280, and
> the Name Constraints must only include email addresses or mailboxes
> for which the CA has confirmed that the subordinate CA is authorized
> to use.

Good. But please state that the cert must not allow anything else than
these two that can be limited. E.g. no code signing subCA, or whatever
else exists / will exist.

E.g. "Must technically ensure that the subCA is limited to the domains.
For WWW server, that means ... RFC... For email, that means ... RFC...
Alternate methods... bugzilla... All others means not explicitly allowed
must be technically impossible."

ianG

unread,
Mar 27, 2012, 8:12:26 PM3/27/12
to dev-secur...@lists.mozilla.org
On 28/03/12 03:46 AM, Kathleen Wilson wrote:
> On 3/26/12 5:50 PM, ianG wrote:
> I'm still trying to work through this...
>
> The currently proposed text has:
> "Each externally-operated subordinate CA that is not technically
> constrained must be publicly disclosed, along with the subordinate CA's
> corresponding Certificate Policy or Certification Practice Statement and
> public attestation of the subordinate CA's conformance to the stated
> certificate verification requirements and other operational criteria by
> a competent independent party or parties with access to details of the
> subordinate CA's internal operations."
>
> I think that this part:
>
> "by a competent independent party or parties with access to details of
> the subordinate CA's internal operations."
>
> means that the unconstrained subCA has to be audited by someone other
> than the CA.
>
> So I think that this option doesn't meet the currently proposed
> requirement, because of the second sentence:
> > b) Have an unconstrained intermediate certificate and be publicly
> > disclosed and audited within scope of the parent CA’s audit. The
> > auditor may rely on an audit of the subCA that is performed by the CA.
>
>
> While it is true that the unconstrained intermediate certificate could
> be audited within the scope of the parent CA's audit. I don't think it's
> true that the auditor may rely on an audit of the subCA that is
> performed by the CA.
>
> Maybe I'm missing something?


:) Audit is not a binary turn-key product. It's a process, not a box.

In a full audit, the auditor relies on a lot of stuff done by the
client. He has to rely on work by internal parties, otherwise it is too
expensive.

In order to tie all this stuff done by the client to the objective (?)
measures in the criteria, the auditor uses something called "the audit
risk model". This simple conceptual model helps the auditor to identify
strong spots and weak spots.

Which is to say, the job of the auditor is already to decide whether to
rely or not on an internal product such as internal audit. We may rely
on him to assess the value of the internal auditor's work; if her work
isn't up to scratch, it's directly within the external auditor's ambit
and skill to know that.

Once this assessment is made, he creates his plan as to how he will
assess the weak spots. So he'll judge any audit material over the
external sub-CA within that context. The only thing *we* need to do is
make sure that the sub-CAs were within context; that the CA didn't
simply contract the auditor to do only the internal ones [0].

This might mean that the auditor declines to rely on internal audit.
But that's his choice *and his job*. If her work doesn't cut it, and he
assesses it as up to standard, then he's taking on the risk - that's his
job and his judgement call. That's why it is called the audit risk model.



iang


[0] Unfortunately, our PKI audit is flawed, because the audit is done
according to the CA's instructions, not to relying party instructions.
The CA can simply turn a blind eye by writing terms of reference /
engagement letter that declares certain areas out of scope.

ianG

unread,
Mar 27, 2012, 8:37:43 PM3/27/12
to dev-secur...@lists.mozilla.org
Hi Ben,

On 28/03/12 04:38 AM, Ben Bucksch wrote:
> First: Thanks, Kathleen for taking our concerns seriously.
>
> On 16.03.2012 22:07, Kathleen Wilson wrote:
>> 9. Each externally-operated subordinate CA must either be audited in
>> accordance with Mozilla’s CA Certificate Policy or must be technically
>> constrained.
>
> One key change: "audited and approved"
>
> If we don't approve subCAs, that basically means that our whole approval
> process is meaningless and a new CA can just get a signature from any
> other existing CA and avoid our process.


No, they can't "just" get a sig. They have to enter into a contract and
auditing framework where the parent CA takes on the whole
responsibility. That means, the CA is taking on the entire shebang, as
if each customer of the sub-CA is now a customer of the parent CA.
That's a big ask.

(We might not see those contract negotiations and resultant audits, but
they should be there. No CEO in his or her right mind is going to enter
these discussions lightly, just for money. And if they do that, they'll
do other bad things.)


> One concrete example: The requirement to be audited doesn't help with
> rogue subCA issued to governments (or any other organization). The gov
> can just get an audit and when it comes out that Iran, China, USA or
> whoever *did* get a subCA and *did* use it to hunt and kill people, the
> CA wasn't actually in violation with the above requirement.


This is waving a spurious claim at audit, which is fun, but we have to
follow it all the way. If such is the case - some audits are bad - we
have to damn all audits, because we have no particular way to determine
whether one audit is better than another. You wave a
political/propaganda flag above, but we could equally wave another
populist flag like the financial system audit failures:

KPMG Chairman said [0]: "We had regulators and governments telling us
not to write down Greek debt in certain countries. They were refusing to
allow accounting firms to adjust, saying they would underwrite a portion
of the debt but refusing to put [that commitment] in writing,"

Are you sure you want to go there? What's the alternate to audit?


>> -- If the EKU includes "TLS WWW server authentication" then the
>> certificate must also include X.509 dNSName Name Constraints as
>> specified in RFC 5280
>> -- If the EKU includes "Email protection" then the certificate must
>> also include rfc822Name Name Constraints as specified in RFC 5280, and
>> the Name Constraints must only include email addresses or mailboxes
>> for which the CA has confirmed that the subordinate CA is authorized
>> to use.
>
> Good. But please state that the cert must not allow anything else than
> these two that can be limited. E.g. no code signing subCA, or whatever
> else exists / will exist.
>
> E.g. "Must technically ensure that the subCA is limited to the domains.
> For WWW server, that means ... RFC... For email, that means ... RFC...
> Alternate methods... bugzilla... All others means not explicitly allowed
> must be technically impossible."


I suspect this is "must ensure by technical and/or contractual means..."

If we are saying that both the end subscriber's cert and the sub-CA cert
must have technical fields in them to ensure limitation according to
EKU, then we no longer have a technical constraint. We might want to
bolster that with contract limitations.


iang


[0] http://financialcryptography.com/mt/archives/001347.html

Stephen Schultze

unread,
Mar 27, 2012, 10:20:36 PM3/27/12
to mozilla-dev-s...@lists.mozilla.org
On 3/27/12 12:46 PM, Kathleen Wilson wrote:
> On 3/26/12 5:50 PM, ianG wrote:
>> On 27/03/12 05:16 AM, Kathleen Wilson wrote:
>>> b) Have an unconstrained intermediate certificate and be publicly
>>> disclosed and audited within scope of the parent CA’s audit. The auditor
>>> may rely on an audit of the subCA that is performed by the CA.

> I'm still trying to work through this...
>
> The currently proposed text has:
> "Each externally-operated subordinate CA that is not technically
> constrained must be publicly disclosed, along with the subordinate CA's
> corresponding Certificate Policy or Certification Practice Statement and
> public attestation of the subordinate CA's conformance to the stated
> certificate verification requirements and other operational criteria by
> a competent independent party or parties with access to details of the
> subordinate CA's internal operations."
>
> I think that this part:
>
> "by a competent independent party or parties with access to details of
> the subordinate CA's internal operations."
>
> means that the unconstrained subCA has to be audited by someone other
> than the CA.
>
> So I think that this option doesn't meet the currently proposed
> requirement, because of the second sentence:
> > b) Have an unconstrained intermediate certificate and be publicly
> > disclosed and audited within scope of the parent CA’s audit. The
> > auditor may rely on an audit of the subCA that is performed by the CA.
>
>
> While it is true that the unconstrained intermediate certificate could
> be audited within the scope of the parent CA's audit. I don't think it's
> true that the auditor may rely on an audit of the subCA that is
> performed by the CA.
>
> Maybe I'm missing something?

I agree that Ian's language, as adapted by you in "b", does not satisfy
the currently drafted language. I think that the currently drafted
language is clear, reflects best-practices, and should prevail. There
is, to begin with, no such thing as (or at least no defined standard
for) a "CA audit." In any case, taking the CA's word that the SubCA's
are "ok" (or whatever a CA audit may claim to assert) seems like an
eminently bad idea. They have the wrong incentives.

I'm not sure why we'd want to enable such behavior, and as such the
language should remain as-is.

Steve

Stephen Schultze

unread,
Mar 27, 2012, 10:30:49 PM3/27/12
to mozilla-dev-s...@lists.mozilla.org
On 3/26/12 2:16 PM, Kathleen Wilson wrote:
> So to comply with the proposed requirement, the options that are
> available to very large enterprise customers with a large number of
> domains are:
>
> a) Have an unconstrained intermediate certificate and be publicly
> disclosed and audited by a competent independent party according to
> Mozilla’s CA Certificate Policy.
>
> b) Have an unconstrained intermediate certificate and be publicly
> disclosed and audited within scope of the parent CA’s audit. The auditor
> may rely on an audit of the subCA that is performed by the CA.
>
> c) Have many technically-constrained intermediate certificates.
>
> d) Use a managed-service, in which the CA operates the subCA's
> intermediate certificates (and related systems), and provides a user
> interface for the customer to issue certificates.

And, to be clear, "d" is only permissible if the managed service permits
issue of certs for a constrained set of domains. Otherwise you have
simply shifted the problem of unconstrained issue by third-parties from
cryptographic to operational delegation... i.e. you get RA breaches
instead of SubCA breaches, but the same effect.

Stephen Schultze

unread,
Mar 27, 2012, 11:22:22 PM3/27/12
to mozilla-dev-s...@lists.mozilla.org
Kathleen, it would be nice to preserve the text of previous drafts
somewhere. Can this process be done in the wiki?

For reference, I quoted the previous draft at the bottom of my message here:
https://groups.google.com/group/mozilla.dev.security.policy/msg/dec6b8e25c810139

I have three major concerns with the proposed draft, which were
addressed in the old text:

#1. The proposed draft does not indicate that name constraints must be
marked critical, as the previous draft did

#2. The proposed draft addresses only third-parties that have control
over key material, but not third-parties that have unconstrained
authority via operational means (e.g. RA's that use "managed-service"
APIs or the like). This is a deadly loophole, as has been demonstrated
with multiple breaches in recent years. The previous draft addressed this.

#3. The proposed draft fails to define "Subordinate CA". As a result,
it is under-inclusive of the actual set of delegated entities. In
addition to the RA/API concern above, I could see CA's trying to
interpret this to *permit* "cross-signing" of non-audited and
non-disclosed third-parties. This is why the previous draft applied the
requirements to, "any external third party that can directly cause the
issuance of a certificate," although perhaps the language could have
been further improved to say, "any third-party that can cause the
issuance of a certificate that chains to the CA's root (by signing such
a certificate itself, by submitting a request to the CA for the
certificate, or by any other mechanism that is not independently
validated by the CA) or that can submit domain validation information to
the CA that is not independently validated by the CA prior to issuing a
certificate."
> Mozilla’s CA Certificate Policy for externally-operated subordinate CAs.
> If we agree to go in this direction, then I believe it would be fine to
> first add the requirement to Mozilla’s CA Certificate Policy, and then
> follow with updating the code in NSS libpkix to enforce it.
>
> I would like to submit the following text for consideration to replace
> the currently proposed text in #9 of
> http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html
>
>
> --
> 9. Each externally-operated subordinate CA must either be audited in
> accordance with Mozilla’s CA Certificate Policy or must be technically
> constrained.
>
> - Each externally-operated subordinate CA that is not technically
> constrained must be publicly disclosed, along with the subordinate CA's
> corresponding Certificate Policy or Certification Practice Statement and
> public attestation of the subordinate CA's conformance to the stated
> certificate verification requirements and other operational criteria by
> a competent independent party or parties with access to details of the
> subordinate CA's internal operations. The subordinate CA's certificate
> verification requirements and operational criteria must satisfy the
> requirements of Mozilla's CA Certificate Policy. The CA's Certificate
> Policy or Certification Practice Statement must indicate where the list
> of publicly disclosed subordinate CAs may be found on the CA's website.
>
> - For an externally-operated subordinate CA to be considered technically
> constrained, the subordinate CA certificate (and any intermediate
> certificates chaining up to that certificate) must include an Extended
> Key Usage (EKU) extension specifying the key usage of the certificates
> it can sign.
>
> -- If the EKU includes "TLS WWW server authentication" then the
> certificate must also include X.509 dNSName Name Constraints as
> specified in RFC 5280, and the Name Constraints must only include
> domains for which the CA has confirmed that the subordinate CA has
> registered or has been authorized by the domain registrant to act on the
> registrant's behalf.
>
> -- If the EKU includes "Email protection" then the certificate must also
> include rfc822Name Name Constraints as specified in RFC 5280, and the
> Name Constraints must only include email addresses or mailboxes for
> which the CA has confirmed that the subordinate CA is authorized to use.
>

Eddy Nigg

<