New Proposed policy for Externally-Operated subCAs

[Kathleen Wilson]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

> XMPP:    start...@startcom.org

> Blog:    http://blog.startcom.org/
> Twitter:http://twitter.com/eddy_nigg

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>