Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

New Proposed policy for Externally-Operated subCAs

496 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