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>

[Eddy Nigg]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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

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


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


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

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


On the other hand, is the technical solution that Carsten outlined
sufficient for large externally-operated subCA enterprise customers?

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

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

Thanks,
Kathleen

[Eddy Nigg]

On 03/22/2012 11:16 PM, From Kathleen Wilson:

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

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

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

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

[ianG]

On 23/03/12 08:16 AM, Kathleen Wilson wrote:
> On 3/22/12 1:28 PM, Eddy Nigg wrote:

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

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

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

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

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

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

Yes, +1, very useful!

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

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

This could be published, as per above.

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

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

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

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



iang

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

Hi Kathleen, Eddy,

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


[snip]

>> Such customers would have a few options:

[...]

>> b) Have many technically-constrained intermediate certificates

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



[snip]

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

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



Regards

[Eddy Nigg]

On 03/23/2012 07:39 PM, From Carsten.D...@t-systems.com:

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

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

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

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

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

[Kathleen Wilson]

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

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

a) Have an unconstrained intermediate certificate and be publicly
disclosed and audited by a competent independent party according to

Mozilla’s CA Certificate Policy.

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

c) Have many technically-constrained intermediate certificates.

d) Use a managed-service, in which the CA operates the subCA's

intermediate certificates (and related systems), and provides a user
interface for the customer to issue certificates.

Correct?

Kathleen

[ianG]

On 27/03/12 05:16 AM, Kathleen Wilson wrote:
> On 3/23/12 8:42 AM, ianG wrote:

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

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

> a) Have an unconstrained intermediate certificate and be publicly
> disclosed and audited by a competent independent party according to

> Mozilla’s CA Certificate Policy.
>

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

> d) Use a managed-service, in which the CA operates the subCA's

> intermediate certificates (and related systems), and provides a user
> interface for the customer to issue certificates.
>
>

> Correct?


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

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

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



iang

[Kathleen Wilson]

I'm still trying to work through this...

The currently proposed text has:

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

I think that this part:

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

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

So I think that this option doesn't meet the currently proposed
requirement, because of the second sentence:

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

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

Maybe I'm missing something?

Kathleen

[Eddy Nigg]

On 03/27/2012 06:46 PM, From Kathleen Wilson:

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

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

[Ben Bucksch]

First: Thanks, Kathleen for taking our concerns seriously.

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

One key change: "audited and approved"

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

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

> -- If the EKU includes "TLS WWW server authentication" then the
> certificate must also include X.509 dNSName Name Constraints as
> specified in RFC 5280

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

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

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

[ianG]

On 28/03/12 03:46 AM, Kathleen Wilson wrote:
> On 3/26/12 5:50 PM, ianG wrote:

> I'm still trying to work through this...
>
> The currently proposed text has:

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

> I think that this part:
>

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

> means that the unconstrained subCA has to be audited by someone other
> than the CA.
>
> So I think that this option doesn't meet the currently proposed
> requirement, because of the second sentence:

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

> While it is true that the unconstrained intermediate certificate could
> be audited within the scope of the parent CA's audit. I don't think it's

> true that the auditor may rely on an audit of the subCA that is
> performed by the CA.
>

> Maybe I'm missing something?

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

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

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

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

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

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



iang


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

[ianG]

Hi Ben,

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

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

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

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

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

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

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

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

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

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


iang


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

[Stephen Schultze]

On 3/27/12 12:46 PM, Kathleen Wilson wrote:
> On 3/26/12 5:50 PM, ianG wrote:
>> On 27/03/12 05:16 AM, Kathleen Wilson wrote:
>>> b) Have an unconstrained intermediate certificate and be publicly
>>> disclosed and audited within scope of the parent CA’s audit. The auditor
>>> may rely on an audit of the subCA that is performed by the CA.

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

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

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

Steve

[Stephen Schultze]

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

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

[Stephen Schultze]

Kathleen, it would be nice to preserve the text of previous drafts
somewhere. Can this process be done in the wiki?

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

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

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

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

#3. The proposed draft fails to define "Subordinate CA". As a result,
it is under-inclusive of the actual set of delegated entities. In
addition to the RA/API concern above, I could see CA's trying to
interpret this to *permit* "cross-signing" of non-audited and
non-disclosed third-parties. This is why the previous draft applied the
requirements to, "any external third party that can directly cause the
issuance of a certificate," although perhaps the language could have
been further improved to say, "any third-party that can cause the
issuance of a certificate that chains to the CA's root (by signing such
a certificate itself, by submitting a request to the CA for the
certificate, or by any other mechanism that is not independently
validated by the CA) or that can submit domain validation information to
the CA that is not independently validated by the CA prior to issuing a
certificate."

> Mozilla’s CA Certificate Policy for externally-operated subordinate CAs.

> If we agree to go in this direction, then I believe it would be fine to

> first add the requirement to Mozilla’s CA Certificate Policy, and then

> follow with updating the code in NSS libpkix to enforce it.
>
> I would like to submit the following text for consideration to replace
> the currently proposed text in #9 of
> http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html
>
>
> --

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

> - Each externally-operated subordinate CA that is not technically

> constrained must be publicly disclosed, along with the subordinate CA's
> corresponding Certificate Policy or Certification Practice Statement and
> public attestation of the subordinate CA's conformance to the stated
> certificate verification requirements and other operational criteria by
> a competent independent party or parties with access to details of the

> subordinate CA's internal operations. The subordinate CA's certificate
> verification requirements and operational criteria must satisfy the
> requirements of Mozilla's CA Certificate Policy. The CA's Certificate
> Policy or Certification Practice Statement must indicate where the list
> of publicly disclosed subordinate CAs may be found on the CA's website.
>

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

> -- If the EKU includes "TLS WWW server authentication" then the
> certificate must also include X.509 dNSName Name Constraints as

> specified in RFC 5280, and the Name Constraints must only include

> domains for which the CA has confirmed that the subordinate CA has
> registered or has been authorized by the domain registrant to act on the
> registrant's behalf.
>

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

[Eddy Nigg]

On 03/28/2012 04:30 AM, From Stephen Schultze:

> And, to be clear, "d" is only permissible if the managed service
> permits issue of certs for a constrained set of domains.

I disagree - the Mozilla policy has clear requirements under which
circumstances a certificate may be issued by a CA. Complying to this
requirement is the key, not limiting the CA.

E.g. it's the CAs responsibility to implement controls for example for
domain control validation which the sub ordinate CA or its subscribers
must perform in order to obtain a certificate.

[Rob Stradling]

On 28/03/12 04:22, Stephen Schultze wrote:
> Kathleen, it would be nice to preserve the text of previous drafts
> somewhere. Can this process be done in the wiki?
>
> For reference, I quoted the previous draft at the bottom of my message
> here:
> https://groups.google.com/group/mozilla.dev.security.policy/msg/dec6b8e25c810139
>
> I have three major concerns with the proposed draft, which were
> addressed in the old text:
>
> #1. The proposed draft does not indicate that name constraints must be
> marked critical, as the previous draft did

Hmmm...

RFC5280 section 4.2 says:
"A certificate-using system MUST reject the certificate if it encounters
a critical extension it does not recognize or a critical extension that
contains information that it cannot process."

Do all of the commonly used desktop browsers, mobile browsers, SSL
toolkits, etc, etc, recognize the Name Constraints extension?
Assuming some don't recognize it, and assuming they follow the "MUST
reject" rule correctly...
Is any CA really going to choose the option which breaks things for even
a relatively small number of clients?

If Mozilla's software recognizes the Name Constraints extension, then
the criticality of the extension is completely insignificant to
Mozilla's userbase.

I was about to write "So I vote that Name Constraints should be
non-critical", but then I noticed that RFC5280 section 4.2.1.10 says:
"Name Constraints...Conforming CAs MUST mark this extension as critical"

RFC5280 section 4.2 also says:
"caution ought to be exercised in adopting any critical extensions in
certificates that might prevent use in a general context."

So maybe we shouldn't use Name Constraints at all!?!

<snip>

[Ned Ulbricht]

On 03/27/2012 08:37 PM, ianG wrote:

> What's the alternate to audit?

In theory?

Let us first suppose that we are designing a critical control system and
are constrained by a mass budget, a power budget, and a realtime budget
(perhaps we are doing rocket-surgery?). Then I don't think there's any
real engineering disagreement on the correct overall approaches to
achieving high reliability. We use multiple redundancy: redundant
sensor systems feeding data to multiple controllers governing redundant
actuators. And we implement voting or consensus to resolve
disagreements among the systems and sub-systems.

Here, we are not constrained by a mass budget or a power budget.

The lack of mass and power constraints, though, does not obviously
indicate to me that the best approach becomes a hierarchy of single
points of system failure. No matter how well-audited.

My intuition is that throwing more money and resources into attempts to
increase reliability for discrete components and black-box sub-systems
(like individual CAs and subCAs) --will not necessarily yield the most
cost-effective improvement in overall system reliability.

Other people might disagree. The obvious counter-argument is that we
really don't need (or can't afford) that much reliability.

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

[ianG]

On 28/03/12 21:35 PM, Ned Ulbricht wrote:
> On 03/27/2012 08:37 PM, ianG wrote:
>
>> What's the alternate to audit?
>
> In theory?
>
> Let us first suppose that we are designing a critical control system and
> are constrained by a mass budget, a power budget, and a realtime budget
> (perhaps we are doing rocket-surgery?). Then I don't think there's any
> real engineering disagreement on the correct overall approaches to
> achieving high reliability. We use multiple redundancy: redundant
> sensor systems feeding data to multiple controllers governing redundant
> actuators. And we implement voting or consensus to resolve
> disagreements among the systems and sub-systems.
>
> Here, we are not constrained by a mass budget or a power budget.

A perspective!

More germane, we are limited by an integrity and honesty budget. The
difference between the above engineering situation could be cast in
terms of sabotage, which is generally an ignored ("accepted") risk in
engineering.

In the corporate / human world we have many agents that are looking to
extract maximum benefit for themselves, and some of those will cross
moral or legal lines to do it. Audit helps to set up governance
controls to minimise, mitigate and surface these activities, and leave
something left of value for the external stakeholder, in those cases
where the external stakeholder is not generally empowered to govern by self.

> The lack of mass and power constraints, though, does not obviously
> indicate to me that the best approach becomes a hierarchy of single
> points of system failure. No matter how well-audited.

A point oft made, but PKI/CA/secure browsing was never ever constructed
for engineering objectives. It was a commercial construct right from
the get-go (back in around mid 1980s).

> My intuition is that throwing more money and resources into attempts to
> increase reliability for discrete components and black-box sub-systems
> (like individual CAs and subCAs) --will not necessarily yield the most
> cost-effective improvement in overall system reliability.

No, it won't. This is accepted. To a large extent we are beyond the
watermark of large numbers, there will be a series of high profile
failures in the future, because we seem to have crossed the rubicon of
attacker interest.

> Other people might disagree. The obvious counter-argument is that we
> really don't need (or can't afford) that much reliability.

We don't get that much reliability - if you look at the overall result
from classical cost-benefit analysis it is hard to calculate much of a
risk value that a user would put on it. But we can't recognise that.
Until some big disaster happens, we can't really call a spade a spade.



Getting back to what is the alternate to audit: There are possibilities.

Along the lines of outsource audit: what we call "open governance"
techniques. A lot of what the CAs do can be opened up for external
checking. A lot can be policed by the people, the users. Traditionally
CAs will say they cannot do this but this is more habit, the old
corporate practice of secrecy in everything, because "competitors" might
get wind... But because of the changing economics of the net,
globalisation, reliable reporting and other things, there is quite a lot
that can be done to open it all up.

FWIW, in a CA I worked with, we have pushed most - like 90% - of the RA
work into an open verifiability posture. There's not a lot of
difficulty in pushing the rest either, we just took the last 10% more
cautiously. (I did less work on the systems side, the core CA, but I'm
pretty sure we can push around 80-90% into a publically verifiable posture.)

A further alternate is to redesign the system so it doesn't need audit.
Other systems seem to get along fine without. Why not borrow from
them? If the result is approximately as reliable, then this might be ok.

Anyway, my point was: if you don't appreciate audit, then there are
alternates. But it'll never fly.

The unstated hard reality tho is that no auditor nor CA nor vendor will
believe you can get away without audit. It's a conversational killer.
So while it is fun to criticise audit and wave ones hands like windmills
and tweak knobs to 11 and increase costs for all ... auditors just sit
their sweetly and suggest ways that assist.

You're stuck with audit :)



iang

[ianG]

Steve,

I think the confusions may be cleared up by my response to Kathleen's
"what am I missing" question.

If that doesn't make sense, feel free to ask again?

iang

On 28/03/12 13:20 PM, Stephen Schultze wrote:
> On 3/27/12 12:46 PM, Kathleen Wilson wrote:

>> On 3/26/12 5:50 PM, ianG wrote:
>>> On 27/03/12 05:16 AM, Kathleen Wilson wrote:
>>>> b) Have an unconstrained intermediate certificate and be publicly
>>>> disclosed and audited within scope of the parent CA’s audit. The
>>>> auditor
>>>> may rely on an audit of the subCA that is performed by the CA.
>

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

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

[Stephen Schultze]

On 3/28/12 4:48 AM, Eddy Nigg wrote:
> On 03/28/2012 04:30 AM, From Stephen Schultze:
>> And, to be clear, "d" is only permissible if the managed service
>> permits issue of certs for a constrained set of domains.
>
> I disagree - the Mozilla policy has clear requirements under which
> circumstances a certificate may be issued by a CA. Complying to this
> requirement is the key, not limiting the CA.
>
> E.g. it's the CAs responsibility to implement controls for example for
> domain control validation which the sub ordinate CA or its subscribers
> must perform in order to obtain a certificate.

I don't fully understand what you mean, but I take it to mean that
you're referring to:

"for a certificate to be used for SSL-enabled servers, the CA takes
reasonable measures to verify that the entity submitting the certificate
signing request has registered the domain(s) referenced in the
certificate or has been authorized by the domain registrant to act on
the registrant's behalf"
https://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html

If so, I agree that this is the relevant text. However, the question
was what options an enterprise customer has, and the proposed solution
was to enable a channel for requests from the enterprise customer to the
CA for requests that are fulfilled without individual domain validation
for each request. The point is that in that case, whatever that
mechanism is (ie: a dedicated "account" for the customer to use a web
interface or API to request these certs), it should be limited to issue
only for domains that have been validated to be under control of the
customer... not every domain in the world.

[Stephen Schultze]

Yes, I had read your response. You argue that auditors should get to
opine on whether to audit SubCAs or to take the CA's word for it --
because that's what they do, and we should just trust them to make the
right decision. I, on the other hand, think it's clearly better to tell
them explicitly that they must audit SubCAs as though they were a CA
themselves (which is what they are).

Steve

[ianG]

On 29/03/12 01:39 AM, Stephen Schultze wrote:
> Yes, I had read your response. You argue that auditors should get to
> opine on whether to audit SubCAs or to take the CA's word for it --
> because that's what they do, and we should just trust them to make the
> right decision. I, on the other hand, think it's clearly better to tell
> them explicitly that they must audit SubCAs as though they were a CA
> themselves (which is what they are).

These two worldviews are not at odds. Auditors will audit the CA and
its associated sub-CAs. They will do so, and include in their
deliberations that sub-CAs are CAs *as long as the subCAs are in scope*.
A point made by WebTrust v2.0 as well.

However, whatever they are engaged to do, they will use all the tools at
their discretion. If they decide to rely on some particular audit --
whether internal, external, independent or otherwise -- as per their
analysis, then they'll do that. They will indeed do that for both
sub-CAs and for the primary CA. They are quite at liberty to rely on
some other audit for some part of the primary CA. They're also at
liberty to rely on some vertically sliced audit over say the RA function
at both primary CA and sub-CAs, but only over some portion of the
functions. Or at something from a systems auditor reviewing the system
security at all installations.

They just won't tell you those details, because at the end of the day,
it is their opinion they are engaged for - not the opinion of another.

Also, possibly what is being missed here is that the Auditor relies
almost entirely - at greater than 90% - on things that the CA says. In
all audit reviews, there will be a caveat to effect "we don't take
responsibility if the client lies."

iang

> Steve
>
> On 3/28/12 8:54 AM, ianG wrote:

[Eddy Nigg]

On 03/28/2012 04:20 PM, From Stephen Schultze:

> If so, I agree that this is the relevant text.

It is.

> However, the question was what options an enterprise customer has,
> and the proposed solution was to enable a channel for requests from
> the enterprise customer to the CA for requests that are fulfilled
> without individual domain validation for each request.

Well, you assumed an "enterprise" scenario, whereas I did not :-)

Of course for a CA that needs to have 5 domains enabled, validate and
put them into the name constraints of the CA certificate. But for the
others, the domain control validation must be control in place - again,
this would be the hosted, managed scenario.

> The point is that in that case, whatever that mechanism is (ie: a
> dedicated "account" for the customer to use a web interface or API to
> request these certs), it should be limited to issue only for domains
> that have been validated to be under control of the customer... not
> every domain in the world.

Why? I mean, a CA that provides certificates to third parties, those
aren't his domains. That's usually the case for all "non-enterprise" CAs.

[Kathleen Wilson]

On 3/28/12 2:53 PM, Ben Wilson wrote:
> Has there already been discussion of revising the definitions for subCAs in
> https://wiki.mozilla.org/CA:SubordinateCA_checklist and
> https://wiki.mozilla.org/CA:Glossary?
>
> "Externally Operated subCA" isn't there.
>
> Will "Third Party" be replaced with a new definition of "Externally Operated
> subCA"?
>


You are correct that those wiki pages will need to be updated if the
proposed policy update (or a version of it) is accepted.

I'm trying to cross one hurdle at a time -- the first, and biggest is to
agree on the policy update.

Thanks,
Kathleen

[Kathleen Wilson]

On 3/27/12 8:22 PM, Stephen Schultze wrote:
> Kathleen, it would be nice to preserve the text of previous drafts
> somewhere. Can this process be done in the wiki?

Here you go:
https://wiki.mozilla.org/CA:CertPolicyUpdates#2011_Draft

> I have three major concerns with the proposed draft, which were
> addressed in the old text:
>
> #1. The proposed draft does not indicate that name constraints must be
> marked critical, as the previous draft did
>

It will have the same effect in Mozilla products whether name
constraints are critical or not, because Mozilla products support name
constraints.

I don't think it is currently reasonable to require name constraints to
be marked as critical, because there are some serious interoperability
issues at the moment. For instance, Apple does not currently support
name constraints in iOS and OS X, and they will not commit to a certain
time frame to have this support available.

At some point I would like to require the name constraints to be marked
as critical, but I think that will have to wait a while longer. In the
meantime, I would really like to make forward progress in regards to
externally-operated subCAs.

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

I had, but removed: “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."

I removed this text because the case of the managed-service (where the
private key is controlled by the CA) is handled by CA/Browser Forum
Baseline Requirements BR 11.1, BR 14.2.4, and BR 17.5.


I also removed the previously proposed:
"10. When an external third party verifies certificate subscriber
information on behalf of the CA, the CA must perform appropriate
additional due diligence, including at least domain name verification,
before the CA may issue the certificate."

Because it is covered by BR 11.1, BR 14.2.4, and BR 17.5.

BR 17.5: "If a Delegated Third Party is not currently audited in
accordance with Section 17 and is not an Enterprise RA, then
prior to certificate issuance the CA SHALL ensure that the domain
control validation process required under Section
11.1 has been properly performed by the Delegated Third Party by either
(1) using an out-of-band mechanism
involving at least one human who is acting either on behalf of the CA or
on behalf of the Delegated Third Party to
confirm the authenticity of the certificate request or the information
supporting the certificate request or (2)
performing the domain control validation process itself."

> #3. The proposed draft fails to define "Subordinate CA". As a result, it
> is under-inclusive of the actual set of delegated entities. In addition
> to the RA/API concern above, I could see CA's trying to interpret this
> to *permit* "cross-signing" of non-audited and non-disclosed
> third-parties. This is why the previous draft applied the requirements
> to, "any external third party that can directly cause the issuance of a
> certificate," although perhaps the language could have been further
> improved to say, "any third-party that can cause the issuance of a
> certificate that chains to the CA's root (by signing such a certificate
> itself, by submitting a request to the CA for the certificate, or by any
> other mechanism that is not independently validated by the CA) or that
> can submit domain validation information to the CA that is not
> independently validated by the CA prior to issuing a certificate."
>

The draft text is still in flux. Please see the current version in item
#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 be technically
constrained. The term "externally-operated" means that the private key
of the intermediate certificate is not created and operated by the CA. ..."

I'm not quite happy with the text of the second sentence, so I would
appreciate thoughts on how to improve it.


All, please note that I have also changed much of the text in the
"technically constrained" bullet points. It's still a work in progress.
I'm trying to figure out exactly what to require, and the technically
correct language to clarify the requirement. I'm looking for feedback on
this.

Also, I saw the discussions about un-deprecating netscapCertType. I
don't want to take this route, because I doubt that any other browser
vendors would pick this up. I would like to use a solution that has the
potential to be used by other browser vendors, e.g. an interoperable
solution.

Kathleen

[Stephen Schultze]

This text does not close the loophole because it still permits the
Delegated Third Party to assert that it has done domain validation
(human or otherwise).

The second sentence is very confusing, and I don't think it accomplishes
what you wanted. Why wouldn't the language I proposed work?

[Stephen Schultze]

On 3/28/12 9:02 PM, Kathleen Wilson wrote:

> On 3/27/12 8:22 PM, Stephen Schultze wrote:
>> Kathleen, it would be nice to preserve the text of previous drafts
>> somewhere. Can this process be done in the wiki?
>
> Here you go:
> https://wiki.mozilla.org/CA:CertPolicyUpdates#2011_Draft

Thanks! I think I wasn't quite as clear as I could have been, however.
What I meant was: Is it possible to do the WorkInProgress stuff *in*
the wiki itself so that everybody can see the change history?

It's hard to keep track of what's changed or even what text we're
discussing when it changes frequently and there's no history. Multiple
rounds of list messages isn't the most efficient way to get clarity.

[Stephen Schultze]

On 3/28/12 1:47 PM, Eddy Nigg wrote:
>> The point is that in that case, whatever that mechanism is (ie: a
>> dedicated "account" for the customer to use a web interface or API to
>> request these certs), it should be limited to issue only for domains
>> that have been validated to be under control of the customer... not
>> every domain in the world.
>
> Why? I mean, a CA that provides certificates to third parties, those
> aren't his domains. That's usually the case for all "non-enterprise" CAs.

I'm confused. Can you clarify? Who is "his"? The CA? We're
discussing the treatment of third-party requests *to* the CA, not the CA
itself. My point is that if someone is permitted to make
non-domain-validated cert requests to a CA, the channel for making those
requests (web interface, API, etc) should restrict the domains to a
predefined list of domains that *has* been domain-validated by the CA.

I don't think that this is controversial, so I'm wondering if we're just
having a misunderstanding.

[ianG]

On 29/03/12 12:02 PM, Kathleen Wilson wrote:

> I don't think it is currently reasonable to require name constraints to
> be marked as critical, because there are some serious interoperability
> issues at the moment. For instance, Apple does not currently support
> name constraints in iOS and OS X, and they will not commit to a certain
> time frame to have this support available.

I must admit ... anything that is marked critical in a large community
is likely to cause no end of trouble. Conceptually it sounds nice and
it solves problems on paper. But in reality, it only takes one
troublemaker and everyone backs away.

> At some point I would like to require the name constraints to be marked
> as critical, but I think that will have to wait a while longer. In the
> meantime, I would really like to make forward progress in regards to
> externally-operated subCAs.

See below for my suggestion about how this is easy.



> ..... is handled by CA/Browser Forum

> Baseline Requirements BR 11.1, BR 14.2.4, and BR 17.5.

Hmmm... does this mean that all applicants must pass BR? What about the
Europeans with their comfortable ETSI?

> I also removed the previously proposed:

....

> Because it is covered by BR 11.1, BR 14.2.4, and BR 17.5.

>> #3. The proposed draft fails to define "Subordinate CA". As a result, it
>> is under-inclusive of the actual set of delegated entities. In addition
>> to the RA/API concern above, I could see CA's trying to interpret this
>> to *permit* "cross-signing" of non-audited and non-disclosed
>> third-parties.

I agree it has to be totally inclusive. By default. And any exceptions
to this have to be explained by the CA and/or auditor.

> The draft text is still in flux. Please see the current version in item
> #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 be technically
> constrained. The term "externally-operated" means that the private key
> of the intermediate certificate is not created and operated by the CA. ..."
>
> I'm not quite happy with the text of the second sentence, so I would
> appreciate thoughts on how to improve it.

:) Not sure what I can do with that, but here's what I think should be
in there:



9. Each CA must either be audited in accordance with Mozilla's CA
Certificate Policy.

* This clause applies equally to subordinate CAs that are operated
independently, externally, enterprise-wise or any otherwise. The
existence of subordinate CAs that are contractually separated does not
obviate the total responsibility that the primary CA has according to
this policy for all its derivative end-user certificates.

* Audits should include all subordinate CAs in scope. Auditors
should detail subsidiary audits where they were materially relied upon.
Where not examined (not so included in scope), the CA must detail the
alternate audits that are relied upon, and they must be examined
separately and according to this policy.

* Where subordinate CAs are contractually or control-wise separated
such that responsibility is stretched on a day-to-day basis, the CA
should impose reliable technical constraints, which are subject to
audit. Technical details of constraints are beyond the scope of this
policy and are written up in a wiki page [somewhere]. They may vary
from time to time.

* peer-to-peer signings or cross-signings should be likewise
detailed. /TBD/

* CAs that outsource some or all of their RA operations will also
need to satisfy this clause and its inclusive nature. In short, the
requirement for RAs to be "in scope" must be addressed, either by
independent audits, by a super-audit over all RAs, or by substantial
internal programs ("internal audit") that itself is examined by the CA's
auditor. The precise mechanism for this is left up to the CA and its
auditor, but may be the subject of later more detailed rules in a wiki
page hereabouts.

10. Criteria acceptable...


In short - less detail, more inclusion, kick out stuff to wiki pages.

> All, please note that I have also changed much of the text in the
> "technically constrained" bullet points. It's still a work in progress.
> I'm trying to figure out exactly what to require, and the technically
> correct language to clarify the requirement. I'm looking for feedback on
> this.

The technical constraints themselves have no place in "policy". See
above, where they are kicked out to some wiki page somewhere. This is
normal. It will cause some to go wobbly at the knees because of the
lack of certainty, but technical certainty in the policy is a far
greater sin.

> Also, I saw the discussions about un-deprecating netscapCertType. I
> don't want to take this route, because I doubt that any other browser
> vendors would pick this up. I would like to use a solution that has the
> potential to be used by other browser vendors, e.g. an interoperable
> solution.

Yeah that would be weird. :)





iang

[Stephen Schultze]

On 3/28/12 11:30 AM, ianG wrote:
> On 29/03/12 01:39 AM, Stephen Schultze wrote:
>> Yes, I had read your response. You argue that auditors should get to
>> opine on whether to audit SubCAs or to take the CA's word for it --
>> because that's what they do, and we should just trust them to make the
>> right decision. I, on the other hand, think it's clearly better to tell
>> them explicitly that they must audit SubCAs as though they were a CA
>> themselves (which is what they are).
>
>
> These two worldviews are not at odds. Auditors will audit the CA and
> its associated sub-CAs. They will do so, and include in their
> deliberations that sub-CAs are CAs *as long as the subCAs are in scope*.
> A point made by WebTrust v2.0 as well.

The only way to know whether the SubCAs were considered in scope is to
have the complete list of SubCAs explicitly stated by the auditor (or
stated by the CA and asserted true by the auditor), declared to be in
scope, and held to the same standard as the primary CA. Perhaps this
could be done as part of the same audit process of the primary CA, but
given the historical tendency of auditors to avoid considering third
parties and the considerable wiggle room in the three steps above, it
seems more straightforward to simply say that they must themselves be
audited as a CA.

It's possible we're both aiming at the same thing, but I'd still argue
that my phrasing is clearer and less prone to creative avoidance (and
another 10 years of auditors declaring it "not our problem.")

You're right that WebTrust 2.0 discusses the issue, but it is
inconclusive on what auditors must actually do:

"Depending on report users’ needs, Subordinate CAs may or may not be
included in the scope of examination. It is important that the system
description and assertion clearly articulate the hierarchy that is in
scope."

Incidentally, the Internet Archive thinks that as of July 22, 2011, the
WebTrust 2.0 for CAs document hadn't been posted to the WebTrust site
(the document itself claims it was released in March 2011 and became
effective July 1 2011):

http://web.archive.org/web/20110722041709/http://www.webtrust.org/homepage-documents/item27839.aspx

[Rob Stradling]

On 29/03/12 02:02, Kathleen Wilson wrote:
<snip>

> Also, I saw the discussions about un-deprecating netscapCertType. I
> don't want to take this route, because I doubt that any other browser
> vendors would pick this up.

Kathleen, why do you doubt this?

Is it just because of the word "netscape"?
(We can always rename it!)

Is it just because the extension's OID is defined under Netscape's OID
arc, rather than under an IETF OID arc?
(The EV Jurisdiction of Incorporation OIDs are defined under Microsoft's
OID arc, and this hasn't proved to be a problem).

> I would like to use a solution that has the potential to be used by
> other browser vendors, e.g. an interoperable solution.

The netscapeCertType extension does have the potential to be used by
other browser vendors. They just need to write code.

If by "an interoperable solution" you're saying that we must not require
new code, then I don't think you're going to find any solution.

If we want to get away with as little new code as possible, consider
these facts:
- Mozilla has fully supported netscapeCertType for years and the code
works.
- Windows (CryptoAPI) and OpenSSL are at least able to parse the
netscapeCertType extension.

> Kathleen

>
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

[Eddy Nigg]

On 03/29/2012 04:10 AM, From Stephen Schultze:

> I'm confused. Can you clarify? Who is "his"? The CA? We're
> discussing the treatment of third-party requests *to* the CA, not the
> CA itself. My point is that if someone is permitted to make
> non-domain-validated cert requests to a CA, the channel for making
> those requests (web interface, API, etc) should restrict the domains
> to a predefined list of domains that *has* been domain-validated by
> the CA.
>
> I don't think that this is controversial, so I'm wondering if we're
> just having a misunderstanding.

Probably - the issuing CA issues end-user certificates to whatever third
parties (subscribers) there are. It's a CA that issues certificates like
any other CA, you usually don't know who your next customer is and for
which domain the certificate is.

The root provides a hosted and controlled intermediate CA as a service
to the issuing CA. It's not an enterprise CA and the possible domains
for example are unknown. The root CA implements a domain control
validation procedure as per BR and Mozilla requirements.

[Kathleen Wilson]

On 3/28/12 1:52 AM, Rob Stradling wrote:
> On 28/03/12 04:22, Stephen Schultze wrote:
>> #1. The proposed draft does not indicate that name constraints must be
>> marked critical, as the previous draft did
>
> Hmmm...
>
> RFC5280 section 4.2 says:
> "A certificate-using system MUST reject the certificate if it encounters
> a critical extension it does not recognize or a critical extension that
> contains information that it cannot process."
>
> Do all of the commonly used desktop browsers, mobile browsers, SSL
> toolkits, etc, etc, recognize the Name Constraints extension?
> Assuming some don't recognize it, and assuming they follow the "MUST
> reject" rule correctly...
> Is any CA really going to choose the option which breaks things for even
> a relatively small number of clients?
>

Yes, this is my concern about requiring name constraints to be marked as
critical.

I would bet that the lack of support in iOS and OS X would mean that if
we did require name constraints to be marked as critical, that it would
be more than just a "relatively small number of clients" that would
break for large enterprise customers.

> If Mozilla's software recognizes the Name Constraints extension, then
> the criticality of the extension is completely insignificant to
> Mozilla's userbase.
>

Correct. Mozilla software will recognize name constraints whether it is
marked critical or not.

> I was about to write "So I vote that Name Constraints should be
> non-critical", but then I noticed that RFC5280 section 4.2.1.10 says:
> "Name Constraints...Conforming CAs MUST mark this extension as critical"
>
> RFC5280 section 4.2 also says:
> "caution ought to be exercised in adopting any critical extensions in
> certificates that might prevent use in a general context."
>
> So maybe we shouldn't use Name Constraints at all!?!
>

Or maybe the RFC needs to be updated in a few places?

Kathleen

[Kathleen Wilson]

On 3/28/12 7:27 PM, ianG wrote:
> Hmmm... does this mean that all applicants must pass BR? What about the
> Europeans with their comfortable ETSI?
>

See proposed text in
http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html
"11. CA operations and issuance of certificates to be used for
SSL-enabled servers must also conform to the current version of the
CA/Browser Forum Baseline Requirements for the Issuance and Management
of Publicly-Trusted Certificates. In the event of inconsistency between
Mozilla's CA Certificate Policy requirements and the Baseline
Requirements, Mozilla's CA Certificate Policy takes precedence."

As per the recent CA Communication and the resulting action items
https://wiki.mozilla.org/CA:Communications#Responses
All of the CAs (with the websites trust bit turned on for their roots)
have stated that they are reviewing the CA/Browser Forum Baseline
Requirements document, and plan to be in compliance by the effective
date of July 1, 2012.

BR 8.3: "The CA SHALL publicly give effect to these Requirements and
represent that it will adhere to the latest published
version. The CA MAY fulfill this requirement by incorporating these
Requirements directly into its Certificate
Policy and/or Certification Practice Statements or by incorporating them
by reference using a clause such as the
following (which MUST include a link to the official version of these
Requirements):
[Name of CA] conforms to the current version of the Baseline
Requirements for the Issuance and
Management of Publicly-Trusted Certificates published at
http://www.cabforum.org. In the event of any inconsistency between this
document and those Requirements, those Requirements take
precedence over this document."

>>> #3. The proposed draft fails to define "Subordinate CA". As a result, it
>>> is under-inclusive of the actual set of delegated entities. In addition
>>> to the RA/API concern above, I could see CA's trying to interpret this
>>> to *permit* "cross-signing" of non-audited and non-disclosed
>>> third-parties.
>
>
> I agree it has to be totally inclusive. By default. And any exceptions
> to this have to be explained by the CA and/or auditor.
>
>
>> The draft text is still in flux. Please see the current version in item
>> #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 be technically
>> constrained. The term "externally-operated" means that the private key
>> of the intermediate certificate is not created and operated by the CA.
>> ..."
>>
>> I'm not quite happy with the text of the second sentence, so I would
>> appreciate thoughts on how to improve it.
>
>
> :) Not sure what I can do with that, but here's what I think should be
> in there:
>
>

The previous text was
"9. The CA must do one of the following for each external third party
that issues certificates. (Any external third party that can directly
cause the issuance of a certificate must be treated as a subordinate CA,
meeting one of the following two requirements.) "


So how about this for the new text:

"9. Each externally-operated subordinate CA must either be audited in
accordance with Mozilla's CA Certificate Policy or 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. ..."


Is "directly cause the issuance of a certificate" clear?

Here's an example of *not* directly causing the issuance of a certificate:
A CA offers a managed-service in which there is a separate subCA
certificate for the customer (the private key is created and operated by
the CA). The CA offers a portal which the customer uses to request
certificates. The CA does some additional processing/checking before
each requested certificate issued, including checking that the domain
name is within the pre-determined list that the customer may use. e.g.
there is an indirection of checks that are performed on the CA-side
before the certificate is issued. It is OK if those checks on the
CA-side are automated.

Normally, I would agree that the technical details belong in the wiki
pages and not in the policy. However, in the case of externally-operated
subCAs, I think we need to be crystal clear about what it means to be
technically constrained. There needs to be specific rules about what the
constraints must be when the externally-operated subCA is not audited by
a "a competent independent party or parties with access to details of
the subordinate CA's internal operations." I think this needs to be
decided up front, and then included directly in the policy, and not in a
separate wiki page.

Note that the proposed language does allow for other ways to be
considered: "Alternate methods of technical controls that are intended
to be used instead of Name Constraints must be publicly reviewed and
approved according to Mozilla's process..."


Kathleen

[Kathleen Wilson]

My understanding is that the old NSS code currently supports EKU in the
way that is being proposed.
(The bug that you filed, #737802, resulted from an unintentional change,
and is being fixed)

I believe that Microsoft also already enforces EKU in this way.

Therefore, between Microsoft and Mozilla/NSS, there is already a large
percentage of the market that supports EKU in this way.

If Microsoft already has a solution implemented, why would they want to
do something with another extension such as netscapeCertType to do what
they can already do?

The changes that I am proposing are:
1) Add the requirement to the policy to use EKU to technically constrain
non-audited, externally-operated subCA.
2) Update libpkix to enforce EKU the way that the old NSS code does.

It seems to me that between Mozilla and Microsoft, these would be the
changes that could happen most efficiently and effectively.

I must admit that I don't have any idea how to go about defining new
OIDs, or renaming and un-deprecating netscapeCertType. On the surface it
sounds like it would take significant time and coordination to make this
happen. On the other hand, we already have an available solution.

Kathleen

[Stephen Schultze]

On 3/29/12 5:09 AM, Eddy Nigg wrote:
> On 03/29/2012 04:10 AM, From Stephen Schultze:
>> I'm confused. Can you clarify? Who is "his"? The CA? We're discussing
>> the treatment of third-party requests *to* the CA, not the CA itself.
>> My point is that if someone is permitted to make non-domain-validated
>> cert requests to a CA, the channel for making those requests (web
>> interface, API, etc) should restrict the domains to a predefined list
>> of domains that *has* been domain-validated by the CA.
>>
>> I don't think that this is controversial, so I'm wondering if we're
>> just having a misunderstanding.
>
> Probably - the issuing CA issues end-user certificates to whatever third
> parties (subscribers) there are. It's a CA that issues certificates like
> any other CA, you usually don't know who your next customer is and for
> which domain the certificate is.
>
> The root provides a hosted and controlled intermediate CA as a service
> to the issuing CA. It's not an enterprise CA and the possible domains
> for example are unknown. The root CA implements a domain control
> validation procedure as per BR and Mozilla requirements.

If that's the case, then I don't think that your "issuing CA" is really
an "Issuing CA" in the language of the BR. It's a third-party that
relays requests to to the CA for domain validation and issuance... a
"reseller" in some CAs' parlance or Registration Authority in the
language of the BR.

BR 1.0 say:
"Issuing CA: In relation to a particular Certificate, the CA that issued
the Certificate. This could be either a Root CA or a Subordinate CA."

"Registration Authority (RA): Any Legal Entity that is responsible for
identification and authentication of subjects of Certificates, but is
not a CA, and hence does not sign or issue Certificates. An RA may
assist in the certificate application process or revocation process or
both."

[Eddy Nigg]

On 03/29/2012 09:07 PM, From Stephen Schultze:

> If that's the case, then I don't think that your "issuing CA" is
> really an "Issuing CA" in the language of the BR. It's a third-party
> that relays requests to to the CA for domain validation and
> issuance... a "reseller" in some CAs' parlance or Registration
> Authority in the language of the BR.
>
> BR 1.0 say:
> "Issuing CA: In relation to a particular Certificate, the CA that
> issued the Certificate. This could be either a Root CA or a
> Subordinate CA."
>
> "Registration Authority (RA): Any Legal Entity that is responsible for
> identification and authentication of subjects of Certificates, but is
> not a CA, and hence does not sign or issue Certificates. An RA may
> assist in the certificate application process or revocation process or
> both."

Yeah, but the certificates are issued by a dedicate intermediate CA
certificate in the name of that entity. Which is btw. what Microsoft
recently required for any RA, but this is pure coincident I think.

[Rob Stradling]

On 29/03/12 18:17, Kathleen Wilson wrote:
> On 3/28/12 1:52 AM, Rob Stradling wrote:

<snip>

>> I was about to write "So I vote that Name Constraints should be
>> non-critical", but then I noticed that RFC5280 section 4.2.1.10 says:
>> "Name Constraints...Conforming CAs MUST mark this extension as critical"
>>
>> RFC5280 section 4.2 also says:
>> "caution ought to be exercised in adopting any critical extensions in
>> certificates that might prevent use in a general context."
>>
>> So maybe we shouldn't use Name Constraints at all!?!
>>
>

> Or maybe the RFC needs to be updated in a few places?

I'll ask on the PKIX list if anyone can explain why RFC5280 requires
Names Constraints to be critical.

> 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.

[Rob Stradling]

On 29/03/12 19:47, Kathleen Wilson wrote:
<snip>

> My understanding is that the old NSS code currently supports EKU in the
> way that is being proposed.

If that is true, then it would be helpful if one of the NSS developers
familiar with the precise behaviour would comment on bug 725351.

725351 asks for this behaviour to be added to NSS, under the assumption
that it does not currently exist.

> (The bug that you filed, #737802, resulted from an unintentional change,
> and is being fixed)
>
> I believe that Microsoft also already enforces EKU in this way.

Yes. See bug 725351.

And I don't suppose the RFC5280 authors are particularly happy about this!

<snip>

[Stephen Schultze]

Why can't a CA simultaneously have a Root CA cert and be defined as a
SubCA of the other cross-signing Root CA? What problem do you perceive
this causing?

On 3/30/12 2:31 PM, Ben Wilson wrote:
> I am thinking that the definition of sub CA needs to clearly exclude a
> cross-signed certificate that is issued by one included Root CA to another
> included Root CA (to establish a trust relationship between the two Root CAs
> for purposes of bridging the chain of trust in legacy systems). I think
> additional language might be needed just to make this clear.

>
> -----Original Message-----
> From: dev-security-policy-bounces+ben=digice...@lists.mozilla.org
> [mailto:dev-security-policy-bounces+ben=digice...@lists.mozilla.org] On
> Behalf Of Stephen Schultze
> Sent: Wednesday, March 28, 2012 8:33 PM
> To: mozilla-dev-s...@lists.mozilla.org
> Subject: Re: New Proposed policy for Externally-Operated subCAs
>
> On 3/28/12 11:30 AM, ianG wrote:

>> On 29/03/12 01:39 AM, Stephen Schultze wrote:
>>> Yes, I had read your response. You argue that auditors should get to
>>> opine on whether to audit SubCAs or to take the CA's word for it --
>>> because that's what they do, and we should just trust them to make
>>> the right decision. I, on the other hand, think it's clearly better
>>> to tell them explicitly that they must audit SubCAs as though they
>>> were a CA themselves (which is what they are).
>>
>>
>> These two worldviews are not at odds. Auditors will audit the CA and
>> its associated sub-CAs. They will do so, and include in their
>> deliberations that sub-CAs are CAs *as long as the subCAs are in scope*.
>> A point made by WebTrust v2.0 as well.
>

> The only way to know whether the SubCAs were considered in scope is to have
> the complete list of SubCAs explicitly stated by the auditor (or stated by
> the CA and asserted true by the auditor), declared to be in scope, and held
> to the same standard as the primary CA. Perhaps this could be done as part
> of the same audit process of the primary CA, but given the historical
> tendency of auditors to avoid considering third parties and the considerable
> wiggle room in the three steps above, it seems more straightforward to
> simply say that they must themselves be audited as a CA.
>
> It's possible we're both aiming at the same thing, but I'd still argue that
> my phrasing is clearer and less prone to creative avoidance (and another 10
> years of auditors declaring it "not our problem.")
>
> You're right that WebTrust 2.0 discusses the issue, but it is inconclusive
> on what auditors must actually do:
>
> "Depending on report users' needs, Subordinate CAs may or may not be
> included in the scope of examination. It is important that the system
> description and assertion clearly articulate the hierarchy that is in
> scope."
>
> Incidentally, the Internet Archive thinks that as of July 22, 2011, the
> WebTrust 2.0 for CAs document hadn't been posted to the WebTrust site (the
> document itself claims it was released in March 2011 and became effective
> July 1 2011):
>
> http://web.archive.org/web/20110722041709/http://www.webtrust.org/homepage-d
> ocuments/item27839.aspx

[Ned Ulbricht]

On 03/30/2012 02:31 PM, Ben Wilson wrote:
> I am thinking that the definition of sub CA needs to clearly exclude a
> cross-signed certificate that is issued by one included Root CA to another
> included Root CA (to establish a trust relationship between the two Root CAs
> for purposes of bridging the chain of trust in legacy systems). I think
> additional language might be needed just to make this clear.

Over a month ago, as a result of Bug #724929, I personally quit
accepting certificates from one of the root CA organizations that
Mozilla continues to ship.

I am aware that another root CA cross-signs a root certificate from that
distrusted organization.

[Kathleen Wilson]

On 3/30/12 11:31 AM, Ben Wilson wrote:
> I am thinking that the definition of sub CA needs to clearly exclude a
> cross-signed certificate that is issued by one included Root CA to another
> included Root CA (to establish a trust relationship between the two Root CAs
> for purposes of bridging the chain of trust in legacy systems). I think
> additional language might be needed just to make this clear.
>

My personal goal for the proposed text is to make sure that each

external third party that can directly cause the issuance of a

certificate is either truly technically constrained, or is audited
according to Mozilla's CA Certificate Policy. In this cross-signing
example, both of the included CAs would already be having the annual
audits according to Mozilla's CA Certificate Policy, and both would
already be publicly listed in the included web page and spreadsheet.

Then, is it truly necessary that such cross-signing relationships be
publicly disclosed? Why? What would be done with this additional
information?

Would it be problematic to require such public disclosure? Can't that
information already be obtained through data such as the EFF SSL
Observatory data? e.g. technically I think that it is already publicly
disclosed, it's just that people have to do some investigation to find
the info.

Kathleen

[John Nagle]

On 3/30/2012 3:26 PM, Kathleen Wilson wrote:
> ... make sure that each

> external third party that can directly cause the issuance of a
> certificate is either truly technically constrained, or is audited
> according to Mozilla's CA Certificate Policy.

That captures the important policy concept in one sentence.

John Nagle
SiteTruth

[ianG]

On 29/03/12 13:32 PM, Stephen Schultze wrote:
> On 3/28/12 11:30 AM, ianG wrote:

>> On 29/03/12 01:39 AM, Stephen Schultze wrote:
>>> Yes, I had read your response. You argue that auditors should get to
>>> opine on whether to audit SubCAs or to take the CA's word for it --
>>> because that's what they do, and we should just trust them to make the
>>> right decision. I, on the other hand, think it's clearly better to tell
>>> them explicitly that they must audit SubCAs as though they were a CA
>>> themselves (which is what they are).
>>
>>
>> These two worldviews are not at odds. Auditors will audit the CA and
>> its associated sub-CAs. They will do so, and include in their
>> deliberations that sub-CAs are CAs *as long as the subCAs are in scope*.
>> A point made by WebTrust v2.0 as well.
>

> The only way to know whether the SubCAs were considered in scope is to
> have the complete list of SubCAs explicitly stated by the auditor (or
> stated by the CA and asserted true by the auditor), declared to be in
> scope, and held to the same standard as the primary CA.

It depends awfully on what you mean by "to know".

If you require to know in a stronger sense then normal then Auditor must
produce some work product related to each sub-CA in public form. This
is kind of what the EV/BR people were getting at when they (ineptly)
wanted the Auditor to witness their key creation - some higher form of
"to know".

On the other hand, the typical thing at the "to know" level is this: the
CA writes in its management assertion what is "in scope". By default,
everything is (although this has sometimes been abused as we know).

That assertion is a statement of significant weight that is made by the CA.

Because of the gravity of the engagement - an auditor instruction no
less - the notion that a CA would write an "in scope" instruction and
then lie is difficult to believe (until it happens of course). I don't
know for sure, but I would guess an assertion would be a standard of
evidence above that of written, and on par with examined-in-court.
I.e., it doesn't get much higher.

Then, again, the Auditor being also aware of the gravity, and
potentially being on the hook for any failures, will *repeat those
words* in her opinion. She generally repeats all the words in the
letter of engagement ... so as to be sure. She may add additional
caveats such as "external RAs are not in scope" where this has arisen in
the progress of the audit -- I remember an auditor did that for Thawte
about 3 years back. Which caveat I then relied upon as auditor of
another CA, and pulled the rug out from those RAs, because their status
was dependent on Thawte's rating.

Short form, if it is in the assertion and opinion, you know. To a
strong standard [0].

If on the other hand you disbelieve the auditor's representations in the
opinion and the CAs representations in their management assertion, etc,
then we have a different issue.

Either they are false, in which case we have *written assertions of
extraordinary gravity that are false* ... or you are wrong ... or you
have misunderstood the subtlety with which auditors can write stuff.

Probably it is the latter. Generally, auditors are total and utter
experts at writing the truth in their opinions. They are also total and
utter experts at steering the non-auditor reader away from certain
issues :) And they charge for that expertise...

But, again, the summary is short and sweet. As long as sub-CAs are "in
scope" then that should be strong.

If you still believe that they will then go on to fudge the issue, then
you have *another issue entirely* which is that you now doubt any word
or claim in the audit at all. So your issue is a forest, not a tree.

What we really need to do is to find a clear example where sub-CAs were
hidden, and this bit us. Then look at the opinion & assertion.

E.g., when the Trustwave thing came up, I asked what was the audit
situation. From memory, the auditor was not informed of this sub-CA.

> Perhaps this
> could be done as part of the same audit process of the primary CA, but
> given the historical tendency of auditors to avoid considering third
> parties and the considerable wiggle room in the three steps above, it
> seems more straightforward to simply say that they must themselves be
> audited as a CA.

It is true that certain CAs did argue that external sub-CAs were out of
scope. And it is also likely that if we go back we will find that the
auditors connived in this game. After all, nobody really cared so why
should they?

> It's possible we're both aiming at the same thing, but I'd still argue
> that my phrasing is clearer and less prone to creative avoidance (and
> another 10 years of auditors declaring it "not our problem.")
>
> You're right that WebTrust 2.0 discusses the issue, but it is
> inconclusive on what auditors must actually do:
>
> "Depending on report users’ needs, Subordinate CAs may or may not be
> included in the scope of examination. It is important that the system
> description and assertion clearly articulate the hierarchy that is in
> scope."

Auditors must always do what they are engaged to do. The scope of the
examination is provided by the CA. So, CAs must be instructed to engage
fully "in scope" w.r.t. sub-CAs, etc.

In that context, the above quote is perfectly clear: What WebTrust 2.0
has said there above is that the auditors should be on the look out for
CAs that try and slide one past. Inclusing, to ask the auditors to
conspire with the CA to also slide it past in opaque auditor language...

What WebTrust 2.0 is saying is "that game is OVER." Auditors are warned
to check that the assertion clearly articulates the scope.

And, vendors as relying parties must also understand that they also have
a responsibility to read the assertions and opinions, and look for those
sad words "sub-CAs are not in scope."

> Incidentally, the Internet Archive thinks that as of July 22, 2011, the
> WebTrust 2.0 for CAs document hadn't been posted to the WebTrust site
> (the document itself claims it was released in March 2011 and became
> effective July 1 2011):
>
> http://web.archive.org/web/20110722041709/http://www.webtrust.org/homepage-documents/item27839.aspx

Huh. The problem with connivance and ineptness is they are
indistinguishable. An open process clears out both these ills.



iang



[0] There are some technical difficulties here, but I'll call them out
of scope for this longgggg email :)

[Stephen Schultze]

Indeed. Or that "can submit domain validation information to the CA
that the CA relies upon for certificate issuance." Or something to that
effect.

[Stephen Schultze]

On 3/30/12 6:26 PM, Kathleen Wilson wrote:
> In this cross-signing example, both of the included CAs would already be
> having the annual audits according to Mozilla's CA Certificate Policy,
> and both would already be publicly listed in the included web page and
> spreadsheet.
>
> Then, is it truly necessary that such cross-signing relationships be
> publicly disclosed? Why? What would be done with this additional
> information?

What if one of your users seeks to customize their own trust list by
distrusting one of the Root CAs, but is unaware that the CA is still
trusted via a cross-signing relationship?

Isn't that Ned's point?
https://groups.google.com/group/mozilla.dev.security.policy/browse_thread/thread/d239c42ef880c71a/58f057cfef2aaebc#eed1f6aa7877b43c

This issue came up repeatedly in the CNNIC/Entrust discussion that
helped spark this SubCA conversation two years ago:

https://groups.google.com/group/mozilla.dev.security.policy/browse_thread/thread/7ba51ca49de0f6cf/fd2fdd60252f3dae

https://groups.google.com/group/mozilla.dev.security.policy/browse_thread/thread/eea04805fbd98045/87b9eab77242b4aft#87b9eab77242b4af

https://groups.google.com/group/mozilla.dev.security.policy/browse_thread/thread/ecc83d8b64b17e1/b7e300fc6c004842#b7e300fc6c004842

https://groups.google.com/group/mozilla.dev.security.policy/browse_thread/thread/17be3bd7e0b33e8c/0ca3da2c6c97c84b#9f0da68675749a6e

> Would it be problematic to require such public disclosure?

No. It would be beneficial.

> Can't that
> information already be obtained through data such as the EFF SSL
> Observatory data? e.g. technically I think that it is already publicly
> disclosed, it's just that people have to do some investigation to find
> the info.

Relying on after-the-fact efforts like EFF Observatory is a fool's game,
and far from comprehensive.

[ianG]

On 31/03/12 09:26 AM, Kathleen Wilson wrote:
> On 3/30/12 11:31 AM, Ben Wilson wrote:
>> I am thinking that the definition of sub CA needs to clearly exclude a
>> cross-signed certificate that is issued by one included Root CA to
>> another
>> included Root CA (to establish a trust relationship between the two
>> Root CAs
>> for purposes of bridging the chain of trust in legacy systems). I think
>> additional language might be needed just to make this clear.
>>
>
>

> My personal goal for the proposed text is to make sure that each

> external third party that can directly cause the issuance of a
> certificate is either truly technically constrained, or is audited

> according to Mozilla's CA Certificate Policy. In this cross-signing

> example, both of the included CAs would already be having the annual
> audits according to Mozilla's CA Certificate Policy, and both would
> already be publicly listed in the included web page and spreadsheet.

So we could end up with a sort of prioritised statement:

Every certificate issued is either

1) issued under direct control and regime of a policy-compliant agent, or
2) issued under the control of a technically constrained regime, as
issued by a policy-compliant agent, or
3) outside policy.

Most cross-signings would fall in 1) above.

> Then, is it truly necessary that such cross-signing relationships be
> publicly disclosed? Why? What would be done with this additional
> information?

I think disclosure of sub-CAs is going to be important. Although for
different reasons than Stephen.

Disclosure is a statement issued at the beginning of a project to
declare conformance in advance. It is useful to lock an agent into
honest behaviour.

In the case where an agent doesn't really have any (other) incentive to
act honestly, this can make all the difference. In the situation where
we can't rely on audit to tell us what these sub-CAs are up to, and we
can't rely on CAs to refuse lucrative but dodgy sub-CA contracts (or
whatever the work-around is when the dust settles on the current
compliance-delta-season) then we need *something* to convince the user
public that CAs are honest actors.

Which is to say, honest CAs and users enter into a sort of open
governance agreement by sharing information. CAs with something to hide
won't do it, of course, because they want to hide their intentions.
Even if they are honest today, they can be lucrative tomorrow. Unless
they've disclosed, that is.


> Would it be problematic to require such public disclosure? Can't that

> information already be obtained through data such as the EFF SSL
> Observatory data? e.g. technically I think that it is already publicly
> disclosed, it's just that people have to do some investigation to find
> the info.

Well. The problem is that we can find stuff from public sources but we
can't do much about it because the CAs don't engage in open discussion.
As one CA said "I refuse to discuss my policies with anyone." As
another CA said, you can't even read our certificate unless you accept
this binding and torturous agreement. All emphasised by recent
breaches, with sparse or unclear guidance as to what happened, including
misinformation, spin, etc.

Open disclosure about practices encourages CAs to also discuss their
practices which helps to build up relationships. On the other hand,
doing everything in secrecy only works when there is a commodity-based
business. The product is substitutable and self-verifying. But nobody
likes the race to the bottom.




iang

[ianG]

On 30/03/12 04:51 AM, Kathleen Wilson wrote:
> On 3/28/12 7:27 PM, ianG wrote:

>> Hmmm... does this mean that all applicants must pass BR? What about the
>> Europeans with their comfortable ETSI?
>>
>
>

yes, sorry, I had forgotten that BR was to be complied with.

Where I was more going was whether there is to be an audit that
specifically targets criteria, written to test BR compliance?

I know this is likely one those CABForum secrets... and they are likely
to spring this on us once all the ink is hopefully laid on paper if not
dried. But knowing the direction of audits is important. It goes
without saying that BR itself has changed a lot.


...

> The previous text was
> "9. The CA must do one of the following for each external third party
> that issues certificates. (Any external third party that can directly
> cause the issuance of a certificate must be treated as a subordinate CA,
> meeting one of the following two requirements.) "
>
>
> So how about this for the new text:

> "9. Each externally-operated subordinate CA must either be audited in
> accordance with Mozilla's CA Certificate Policy or 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. ..."
>
>

> Is "directly cause the issuance of a certificate" clear?


Not really, to me at least :( In this case, directly means "without
going through the CA's processes which clearly shows the nexus of
responsibility..." But there will be plenty of quibbles on which
processes are essential, which give rise to a "CA" issuance event, etc.

I fully expect after all this is done, the CAs will sit down and work
out how to arbitrage the rules. This is why it is critically important
to say that regardless of whatever rules we lay out, the CA is
ultimately responsible. (Yes, this brings in quite interesting
ramifications for cross-signing :)

CAs might figure out a way to hide something or other, but if anything
goes wrong, then the CA is responsible, and it cannot bow out by waving
contracts or disclaimers or novel business models. Our mission isn't to
stop them inventing new ways to slide out of whatever rules we lay out,
but to protect our users.

How about this for some text:

=====
9. Any part or the whole of the CA business model (including RA and
sub-CA components) may be outsourced to a third party. In such a case,
the parent CA remains entirely responsible to Mozilla Foundation for the
actions of its agents. The CA will be required to show that the agents
are operating in compliance with this model, by one of:

a. document the controls as per normal, include the agent fully
within the scope of its routine audits, and instruct the auditor to name
substantial agents.
b. publish the details of a policy-compliant audit over independent
agents, or
c. describing technical constraints on the operation of that agent
such that actions and risks are substantially and severely limited.

======



(Where, c. is to be debated with each root's application. If we can
establish a case history of appropriate methods, then that might not
work. This will be much like the way the current CAs put each others'
domain verification under their scanning electron microscope....)

(point being here that I don't see we have much faith in the technical
constraints at the certificate / x.509 level... maybe they are
worthless? we will need to prove it in several cases before we can rely
on it simply in a policy diktat.)

> Here's an example of *not* directly causing the issuance of a certificate:
> A CA offers a managed-service in which there is a separate subCA
> certificate for the customer (the private key is created and operated by
> the CA). The CA offers a portal which the customer uses to request
> certificates. The CA does some additional processing/checking before
> each requested certificate issued, including checking that the domain
> name is within the pre-determined list that the customer may use. e.g.
> there is an indirection of checks that are performed on the CA-side
> before the certificate is issued. It is OK if those checks on the
> CA-side are automated.

That is fine. I would suggest the CA simply include that within scope
of the audit, and describe the arrangement in CPS.

...
>> In short - less detail, more inclusion, kick out stuff to wiki pages.
>>
>
>

> Normally, I would agree that the technical details belong in the wiki
> pages and not in the policy. However, in the case of externally-operated
> subCAs, I think we need to be crystal clear about what it means to be
> technically constrained. There needs to be specific rules about what the
> constraints must be when the externally-operated subCA is not audited by
> a "a competent independent party or parties with access to details of
> the subordinate CA's internal operations." I think this needs to be
> decided up front, and then included directly in the policy, and not in a
> separate wiki page.

I see your point, but I worry that it is unobtainable.

The problem I have is well laid out in the description of constraints
that we've seen in recent weeks. It has raised substantial doubt. If
it for example ends up being flawed, however that happens, do we still
have technical constraints? Are we facing a situation where a bug in
the future -- or a rogue vendor - or a fast purchaser - or an innovative
CA -- could render the whole thing worthless?

E.g., Apple's Safari doesn't follow the critical extension. Chrome
doesn't follow the green convention.

So, we are faced with a cooperative solution involving 6 vendors, 100
CAs, and a million subscribers in order to create a claim of "technical
constraint." I can see for example that a powerful customer might
decide to pay for for certs that don't have the critical extension in
them ... and thus break the whole cooperation.

Hence, I'm thinking that if we are to discuss technical constraints,
then they have to be pushed over to the CPS/application process. CA to
disclose upfront, we all to review process, and ensure compliance by
normal methods - audit over disclosures, and open governance.

> Note that the proposed language does allow for other ways to be
> considered: "Alternate methods of technical controls that are intended
> to be used instead of Name Constraints must be publicly reviewed and
> approved according to Mozilla's process..."

Right, that's more what I was suspecting. Maybe the difference is that
I hope for a set of 0 in the policy, where you are hoping for a set of 1 :)




iang

[Ben Bucksch]

On 28.03.2012 02:37, ianG wrote:

>> The gov can just get an audit
>
> If such is the case - some audits are bad - we have to damn all audits

No, that doesn't follow. There's a big difference between GeoTrust
telling the audit firm "yes, we don't follow our own processes here, but
here's $$$, let us pass" and the audit company rightly refusing that,
and a government like USA, China or Iran telling you "yes, we don't
follow the GeoTrust policy, but we're the CIA, and this is national
security, you let us pass, or else..." or "look, you're the auditor, but
we have your child. You let us pass, and you don't tell anyone, or else...".

To me, the idea that an audit company would withstand the will of a
government is ridiculous.

>> E.g. "Must technically ensure that the subCA is limited to the domains.
>> For WWW server, that means ... RFC... For email, that means ... RFC...
>> Alternate methods... bugzilla... All others means not explicitly allowed
>> must be technically impossible."
>
> I suspect this is "must ensure by technical and/or contractual means..."

No, not contractual. Wherever we have the possibility to technically
enforce something, we have to do that.

Ben

[Gervase Markham]

On 28/03/12 04:22, Stephen Schultze wrote:

> Kathleen, it would be nice to preserve the text of previous drafts
> somewhere. Can this process be done in the wiki?

https://wiki.mozilla.org/index.php?title=CA:CertPolicyUpdates&action=history
?

Click any dated link.

Gerv

[Phillip Hallam-Baker]

Sorry for the late reply, the reason is they don't understand the
purpose of the critical flag.

They think it means 'very important'.

What it actually means is 'break if you don't understand this
extension' which is not the same thing at all.

On Thu, Mar 29, 2012 at 3:48 PM, Rob Stradling <rob.st...@comodo.com> wrote:
> On 29/03/12 18:17, Kathleen Wilson wrote:
>>
>> On 3/28/12 1:52 AM, Rob Stradling wrote:
>
> <snip>
>
>>> I was about to write "So I vote that Name Constraints should be
>>> non-critical", but then I noticed that RFC5280 section 4.2.1.10 says:
>>> "Name Constraints...Conforming CAs MUST mark this extension as critical"
>>>
>>> RFC5280 section 4.2 also says:
>>> "caution ought to be exercised in adopting any critical extensions in
>>> certificates that might prevent use in a general context."
>>>
>>> So maybe we shouldn't use Name Constraints at all!?!
>>>
>>
>> Or maybe the RFC needs to be updated in a few places?
>
>
> I'll ask on the PKIX list if anyone can explain why RFC5280 requires Names
> Constraints to be critical.
>
>
>> 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.

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

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

[Kathleen Wilson]

I'm OK with using (or adding) text along those lines, except for b and
c. For b, we had many discussions to come up with the text that is
currently proposed, and that particular sub-bullet has been quite stable
for many months now. For c, I want technical constraints that can be
controlled within NSS.

> (point being here that I don't see we have much faith in the technical
> constraints at the certificate / x.509 level... maybe they are
> worthless? we will need to prove it in several cases before we can rely
> on it simply in a policy diktat.)
>

I am trying to define and reach consensus on technical constraints that
involve something being in the intermediate certificate and checked by
NSS. If we can agree on a solution along these lines, then I think we
would have faith in such technical constraints. The problem that we are
having is in agreeing on what the solution is. I think at has to be
something regarding some sort of key usage type extension combined with
name constraints. We're all in agreement about name constraints (I view
the discussion about criticality as not necessary to Mozilla's policy).
The part of the solution that needs more work has to do with the ability
for the intermediate certificate to specify which types of key usages
certs chaining up to it can have -- this doesn't appear to exist in an
RFC yet.

Kathleen

[Brian Smith]

(Quotes are from the proposed inclusion policy)

"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."

AFAICT, the pathLenConstraint only becomes security-critical for us when there are no useful name constraints. Accordingly, I think this requirement should be removed when there are name constraints limiting the cert to a particular set of TLD+1s. There are security benefits to being able to issue sub-sub-CA certificates within an organization (e.g. one per department, or one per physical office or whatever). And, if we make the change I suggest below, making name constraints the only acceptable mechanism in the policy unless/until the policy is amended, then we can remove this pathLenConstraint clause completely.

"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 extended key usage(s) it is authorized to issue certificates for, and the EKU must not included the anyExtendedKeyUsage KeyPurposeId."

Instead of blacklisting the anyExtendedKeyUsage, why not whitelist the acceptable EKUs? It is error-prone to blacklist specific EKUs. For example, you omitted the step-up/SGC EKUs. It is good for us to not accept the step-up/SGC EKUs but my reading of the policy is that they are allowed without any name constraint requirements, which is wrong.

"If certificates chaining up to the technically constrained externally-operated subordinate CA certificate may be used for TLS WWW server authentication, then the EKU of the subordinate CA's intermediate certificate(s) must include id-kp-serverAuth. Additionally, the subordinate CA's intermediate certificate(s) 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."

I think this means that the top-level domains must be validated but not sub-domains. e.g. control of google.com should be validated by the issuing CA and then the name constraint can become *.google.com, right? Or, in other words, a CA can sell name-constrained sub-CA certificates that are very much like wildcard certificates without any new inconvenience created by this change, right? That seems good to me.

It is good to require that such sub-CA certificates do not contain the EV OIDs, because the EE certs won't meet the EV requirements. (In particular, EV is somewhat of an anti-phishing mechanism, but there's nothing stopping a bad guy from using a wildcard *.america.com cert or a *.america.com sub-CA to phish bankofamerica.com.)

"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."

Why is this part useful? Aren't we effectively defining a variant of wildcard certificates? If so, the requirements for wildcard certificates should be sufficient to cover these name-constrained sub-CA certificates. And, if that is the case, I would rather simplify the policy by removing this requirement. Also, this requirement is way too vague; how would we determine if a CA complied with this requirement or not? If we have specific requirements that we want added to the contracts, we should define those requirements in the policy.

I think it would be good to add one additional requirement: The domains listed in the sub-CA's name constraints for a given sub-CA should all belong to a single organization (which would include any parent-child relationships like Mozilla Foundation and Mozilla Corporation). (Perhaps this is something that should be made a more general requirement that applies to EE certificates as well as sub-CA certificates.)

"Alternate methods of technical controls that are intended to be used instead of Name Constraints 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, Applying for root inclusion in Mozilla products, provides further details about how to submit a formal request. "

We should remove this part. Instead of processing one-off exceptions to the policy, we should modify the policy to allow the new mechanism and define the parameters for its use. This way, every CA should operate under the same policy. This helps us to simplify the policy by removing the vague "additional technical and/or contractual restrictions" requirement. AFAICT, the process for a change to the policy vs. allowing one-off exceptions would not be different anyway.

For example, let's say a root CA sub-CA found the name constraints to be too restrictive for some customer. Then, the root CA might propose some counter-signing mechanism where one of their intermediates, known by us to be owned and operated by the root CA, counter-signs every certificate issued by the sub-CA. This would show that the root CA knew about the certificate and thus were capable of verifying domain control. This type of system could probably be made to be an acceptable technical constraint, based on the way our current policy works. But, if/when a CA needs such a mechanism, we should amend the CA inclusion policy to define exactly how it should work.

Cheers,
Brian

[Brian Smith]

Stephen Schultze wrote:
> On 3/30/12 6:26 PM, Kathleen Wilson wrote:

> > In this cross-signing example, both of the included CAs would
> > already be having the annual audits according to Mozilla's CA
> > Certificate Policy, and both would already be publicly listed
> > in the included web page and spreadsheet.
> >

> > Then, is it truly necessary that such cross-signing relationships
> > be publicly disclosed? Why? What would be done with this
> > additional information?
>

> What if one of your users seeks to customize their own trust list by
> distrusting one of the Root CAs, but is unaware that the CA is still
> trusted via a cross-signing relationship?

If we were to have Gecko enforce the policy on name-constrained sub-CAs, then we would automatically stop trusting these cross-signings, because the cross-signed certificates would be seen as sub-CA certificates without the mandatory name constraints, right?

Because our CAs have their own unconstrained intermediates, we would have to have a whitelist of intermediate certs that are known to be owned and operated by the root CAs, so that we know which ones we would not enforce name constraints on. We simply would not include any cross-signing certificates in this set.

Or, in other words, we would just stop trusting the cross-signing certificates completely, AFAICT.

Cheers,
Brian

[ianG]

On 5/04/12 03:15 AM, Brian Smith wrote:
> (Quotes are from the proposed inclusion policy)

....

> "Alternate methods of technical controls that are intended to be used instead of Name Constraints 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, Applying for root inclusion in Mozilla products, provides further details about how to submit a formal request."
>
> We should remove this part. Instead of processing one-off exceptions to the policy, we should modify the policy to allow the new mechanism and define the parameters for its use.

Just on the "how to" issue...

As a good practice, policy should never include methods. It should list
targets, goals, requirements, objectives. Methods to achieve those
things should be kicked out to a separate document, perhaps referenced
if necessary.

> This way, every CA should operate under the same policy. This helps us to simplify the policy by removing the vague "additional technical and/or contractual restrictions" requirement. AFAICT, the process for a change to the policy vs. allowing one-off exceptions would not be different anyway.

By including the list of methods by reference in the policy, it is "in"
the policy for regulatory purposes. But just organised in a more usable
fashion.


iang

[John Nagle]

Should CAs, as well as sub-CAs, be subject to
name constraints?

There are CAs which operate only within a TLD.
The US Government and DOD have several which operate
only within ".gov" and ".mil", for example. If limiting
CAs to a set of TLDs was enforced, that would reduce the
risks associated with government-run CAs.

This would allow Firefox to have more of the DOD CAs
listed, for example. There are public web sites in
".mil" with certs issued by DOD CAs not recognized by
Firefox. Technically restricted CAs with clear authority
over their TLD need less auditing than those which can issue
certs for any domain.

John Nagle

[James May]

> ______________________________**_________________
> dev-security-policy mailing list
> dev-security-policy@lists.**mozilla.org<dev-secur...@lists.mozilla.org>
> https://lists.mozilla.org/**listinfo/dev-security-policy<https://lists.mozilla.org/listinfo/dev-security-policy>
>

That sort of narrowing of scope certainly makes sense to me.

It could even become a selling point for certain TLDs if there was a
restricted number of CAs or jurisdictions able to issue certs.

[ianG]

On 6/04/12 04:26 AM, John Nagle wrote:
> Should CAs, as well as sub-CAs, be subject to
> name constraints?

It's a possibility - there are pros and cons. I'd wait until it was
proven for sub-CAs first though.

iang

> There are CAs which operate only within a TLD.
> The US Government and DOD have several which operate
> only within ".gov" and ".mil", for example. If limiting
> CAs to a set of TLDs was enforced, that would reduce the
> risks associated with government-run CAs.
>
> This would allow Firefox to have more of the DOD CAs
> listed, for example. There are public web sites in
> ".mil" with certs issued by DOD CAs not recognized by
> Firefox. Technically restricted CAs with clear authority
> over their TLD need less auditing than those which can issue
> certs for any domain.
>
> John Nagle