RE-WRITE of proposed subCA Policy, item #9

[Kathleen Wilson]

All,

As you know, the currently proposed policy for subCAs is in section #9
of
http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html

Please review the following text which is meant to be a replacement of
the currently proposed subCA policy. There is much to be discussed about
this new text, and I will greatly appreciate your constructive input.

For those of you who have already begun working towards the currently
proposed subCA policy, I thank you for your diligence and I look forward
to learning how this new version would impact you, and if you have
suggestions about how to improve it.

I am very appreciative of the feedback and input that has been provided
by many members of this community, and I would like to specially thank
Brian Smith, Ryan Sleevi and Tom Lowenthal for their patience and
continued efforts to help me re-write this proposed policy.

Here's the new proposal:

~~~
9. All certificates that are technically capable of issuing
certificates, and which directly or transitively chain to a certificate
included in Mozilla's CA Certificate Program, MUST be operated in
accordance with Mozilla's CA Certificate Policy and must either be
technically constrained or be publicly disclosed and audited.

- A certificate is deemed as technically capable of issuing certificates
if it lacks a critical X.509v3 basicConstraints extension with the isCA
boolean explicitly false. The term "subordinate CA" below refers to any
organization or legal entity that is in possession or control of a
certificate that is technically capable of issuing certificates.

- These requirements include all cross-certified certificates which
chain to a certificate that is included in Mozilla's CA Certificate Program.

- For a certificate to be considered technically constrained, the
certificate MUST include an Extended Key Usage (EKU) extension
specifying all extended key usages that the subordinate CA is authorized
to issue certificates for. The anyExtendedKeyUsage MUST NOT appear
within this extension.

-- If the certificate includes the id-kp-serverAuth extended key usage,
then the certificate MUST include the Name Constraints X.509v3
extension. The Name Constraints extension MUST contain a dNSName
permittedSubtrees constraint that only contains domains for which the
issuing 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 there are no such dNSNames (e.g. because the certificate is
for issuing IP-address-based certificates), then the certificate must
contain a dNSNames constraint that prohibits all DNS names.

-- If the certificate includes the id-kp-emailProtection extended key
usage, then all end-entity certificates MUST only include e-mail
addresses or mailboxes that the issuing CA has confirmed (via technical
and/or business controls) that the subordinate CA is authorized to use.

- All certificates that are technically capable of issuing certificates,
that are not technically constrained, and which directly or transitively
chain to a certificate included in Mozilla's CA Certificate Program MUST
be publicly disclosed by the CA that has their certificate included in
Mozilla's CA Certificate Program. The CA with a certificate included in
Mozilla's CA Certificate Program MUST disclose this information prior to
any such subordinate CA issuing certificates. All disclosure of
certificates MUST be made freely available and without additional
requirements, including, but not limited to, registration,legal
agreements, or restrictions on redistribution of the certificates in
whole or in part. The Certificate Policy or Certification Practice
Statement of the CA that has their certificate included in Mozilla's CA
Certificate Program must specify where on that CA's website all such
public disclosures are located. For a certificate to be considered
publicly disclosed, the following information MUST be provided:
-- The full DER-encoded X.509 certificate
-- The corresponding Certificate Policy or Certification Practice
Statement used by the subordinate CA
-- Annual public attestation of conformance to the stated certificate
verification requirements and other operational criteria by a competent
independent party or parties with access to the details of the
subordinate CA's internal operations.
~~~


To reiterate, the above text is proposed to replace what is currently in
#9 of
http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html.

I look forward to your constructive input.

Thanks,
Kathleen

[David E. Ross]

On 10/15/12 3:26 PM, Kathleen Wilson wrote [in part]:

> All,
>
> As you know, the currently proposed policy for subCAs is in section #9
> of
> http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html
>
> Please review the following text which is meant to be a replacement of
> the currently proposed subCA policy. There is much to be discussed about
> this new text, and I will greatly appreciate your constructive input.
>

Where the policy uses the phrase "issuing certificates", do you not mean
"signing certificates" and similarly for "issued certificates" etc. As
an amateur in this, I thought the end users create their own
certificates and then have them signed by a root or intermediate
certificate.

--

David E. Ross
<http://www.rossde.com/>

Anyone who thinks government owns a monopoly on inefficient, obstructive
bureaucracy has obviously never worked for a large corporation.
© 1997 by David E. Ross

[David E. Ross]

On 10/15/12 3:26 PM, Kathleen Wilson wrote [in part]:

> All,
>
> As you know, the currently proposed policy for subCAs is in section #9
> of
> http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html
>
> Please review the following text which is meant to be a replacement of
> the currently proposed subCA policy. There is much to be discussed about
> this new text, and I will greatly appreciate your constructive input.
>

[snipped]

>
> - All certificates that are technically capable of issuing certificates,
> that are not technically constrained, and which directly or transitively
> chain to a certificate included in Mozilla's CA Certificate Program MUST
> be publicly disclosed by the CA that has their certificate included in
> Mozilla's CA Certificate Program. The CA with a certificate included in
> Mozilla's CA Certificate Program MUST disclose this information prior to
> any such subordinate CA issuing certificates.

The "which" in line 2 should be "that".

The last line above should read:
"any such subordinate CA is allowed to issue certificates."

or (given my prior comment about "issue" vs "sign"):
"any such subordinate CA is allowed to sign certificates."

[Eddy Nigg]

On 10/16/2012 12:44 AM, From David E. Ross:

> Where the policy uses the phrase "issuing certificates", do you not
> mean "signing certificates" and similarly for "issued certificates"
> etc. As an amateur in this, I thought the end users create their own
> certificates and then have them signed by a root or intermediate
> certificate.

No, end-users would prepare a certificate signing request and submit
that to the CA for signing. Only the issuer "signs" or "issues"
certificates. Usually that's the CA.

--
Regards

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

[Rob Stradling]

On 15/10/12 23:26, Kathleen Wilson wrote:
<snip>

> - A certificate is deemed as technically capable of issuing certificates
> if it lacks a critical X.509v3 basicConstraints extension with the isCA
> boolean explicitly false.

I understand, and support, your desire to ensure that the Basic
Constraints extension is used effectively. However...

1. Both RFC5280 and the CABForum Baseline Requirements permit the Basic
Constraints extension to be excluded from end-entity certificates. And,
when it is included, it can be either critical or non-critical.
Here are some relevant quotes from RFC5280:
"If the subject is a CA (e.g., the basic constraints extension, as
discussed in Section 4.2.1.9, is present and the value of cA is
TRUE)"
"(k) If certificate i is a version 3 certificate, verify that the
basicConstraints extension is present and that cA is set to
TRUE. (If certificate i is a version 1 or version 2
certificate, then the application MUST either verify that
certificate i is a CA certificate through out-of-band means
or reject the certificate. Conforming implementations may
choose to reject all version 1 and version 2 intermediate
certificates.)
...If check...(k)...fails, the procedure terminates,
returning a failure indication and an appropriate reason."

2. I can't accept the "explicitly" in "explicitly false". The ASN.1
definition makes it perfectly clear that the cA field is set to FALSE
_implicitly_ when it is omitted from the encoded certificate.
BasicConstraints ::= SEQUENCE {
cA BOOLEAN DEFAULT FALSE,
pathLenConstraint INTEGER (0..MAX) OPTIONAL }

So I propose that you change this clause to...

"- A certificate is deemed as technically capable of issuing

certificates if it is a version 1 or version 2 certificate, or if it
contains the X.509v3 basicConstraints extension with the cA boolean set
to true."

(Alternatively, if it really is your intention to add a completely new
requirement that the Basic Constraints extension MUST be present in
every end-entity certificate, then this isn't a problem for Comodo
because we have always included the Basic Constraints extension in every
certificate we issue.
But I'm sure it would be a problem for some other CAs, hence my proposed
change!)

<snip>

> - For a certificate to be considered technically constrained, the
> certificate MUST include an Extended Key Usage (EKU) extension
> specifying all extended key usages that the subordinate CA is authorized
> to issue certificates for. The anyExtendedKeyUsage MUST NOT appear
> within this extension.
>
> -- If the certificate includes the id-kp-serverAuth extended key usage

<snip>

> -- If the certificate includes the id-kp-emailProtection extended key usage

<snip>

For id-kp-codeSigning, why don't you also demand that technically
constrained subordinate CA certificates MUST contain a directoryName
permittedSubtrees constraint, so that end-entity Code Signing
Certificates may only be issued to Organization Name(s)/Address(es) that
the CA has confirmed that the Subordinate CA is authorized to issue to?

<snip>

> The Certificate Policy or Certification Practice
> Statement of the CA that has their certificate included in Mozilla's CA
> Certificate Program must specify where on that CA's website all such
> public disclosures are located. For a certificate to be considered
> publicly disclosed, the following information MUST be provided:
> -- The full DER-encoded X.509 certificate
> -- The corresponding Certificate Policy or Certification Practice
> Statement used by the subordinate CA
> -- Annual public attestation of conformance to the stated certificate
> verification requirements and other operational criteria by a competent
> independent party or parties with access to the details of the
> subordinate CA's internal operations.

I think it would be useful to require the CAs that have their
certificate(s) included in Mozilla's CA Certificate Program to post this
information on their websites in some sort of standardized format, so
that it is not an insurmountable task for interested parties to
regularly retrieve and analyze all public disclosures.

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

[Stephen Schultze]

It seems to me that the proposed text simply adds a greater degree of
specificity on top of RFC5280 and CABForum, which has been something
that Mozilla has done across the board in the interest of its end-users.

You aren't claiming that there's a conflict between the texts, right?

> 2. I can't accept the "explicitly" in "explicitly false". The ASN.1
> definition makes it perfectly clear that the cA field is set to FALSE
> _implicitly_ when it is omitted from the encoded certificate.
> BasicConstraints ::= SEQUENCE {
> cA BOOLEAN DEFAULT FALSE,
> pathLenConstraint INTEGER (0..MAX) OPTIONAL }
>
> So I propose that you change this clause to...
> "- A certificate is deemed as technically capable of issuing
> certificates if it is a version 1 or version 2 certificate, or if it
> contains the X.509v3 basicConstraints extension with the cA boolean set
> to true."

Again, this requirement is not in conflict with the spec but rather an
added level of specificity that (in combination with the criticality
bit) will, in practice, ensure that any clients that respect the
critical bit will behave as expected (Mozilla products included).

I support the original language proposed by Kathleen.

> (Alternatively, if it really is your intention to add a completely new
> requirement that the Basic Constraints extension MUST be present in
> every end-entity certificate, then this isn't a problem for Comodo
> because we have always included the Basic Constraints extension in every
> certificate we issue.
> But I'm sure it would be a problem for some other CAs, hence my proposed
> change!)

[snip]

> I think it would be useful to require the CAs that have their
> certificate(s) included in Mozilla's CA Certificate Program to post this
> information on their websites in some sort of standardized format, so
> that it is not an insurmountable task for interested parties to
> regularly retrieve and analyze all public disclosures.

+1 to this, absolutely. In requiring this, we should avoid the pitfall
of trying to create some new complicated spec that takes years to hash
out. robots.txt could be inspiration, and the format should be
definable by a couple of smart Mozillans in a couple of hours.

Steve

[Rob Stradling]

On 16/10/12 15:09, Stephen Schultze wrote:
<snip>

> You aren't claiming that there's a conflict between the texts, right?

There are 8 possibilities:
1. No Basic Constraints extension. v1 or v2 certificate.
2. No Basic Constraints extension. v3 certificate.
3. Non-critical Basic Constraints extension with cA=FALSE (implicitly).
4. Critical Basic Constraints extension with cA=FALSE (implicitly).
5. Non-critical Basic Constraints extension with cA=FALSE (explicitly).
6. Critical Basic Constraints extension with cA=FALSE (explicitly).
7. Non-critical Basic Constraints extension with cA=TRUE (explicitly).
8. Critical Basic Constraints extension with cA=TRUE (explicitly).

RFC5280 regards types 7 and 8 as CA certificates (aka "technically
capable of issuing certificates"), types 2, 3, 4, 5 and 6 as end-entity
certificates, and requires type 1 to be either rejected or to have its
CA status verified through out-of-band means.

In contrast, Kathleen's proposed text regards types 1, 2, 3, 4, 5, 7 and
8 as CA certificates, and so all end-entity certificates must be type 6!

All end-entity certificates issued by Comodo are type 4. If I had in
front of me a complete set of all end-entity certs issued by all of the
CAs, I would expect to find that they are all type 2, 3 or 4.

In other words, I would expect to find ZERO certificates that fit
Kathleen's proposed definition (type 6) of a cert that is _not_
"technically capable of issuing certificates"! This would mean that
every SSL Certificate in the world would be regarded as a Subordinate CA
Certificate!!!

<snip>

>> I think it would be useful to require the CAs that have their
>> certificate(s) included in Mozilla's CA Certificate Program to post this
>> information on their websites in some sort of standardized format, so
>> that it is not an insurmountable task for interested parties to
>> regularly retrieve and analyze all public disclosures.
>

> +1 to this, absolutely. In requiring this, we should avoid the pitfall
> of trying to create some new complicated spec that takes years to hash
> out. robots.txt could be inspiration, and the format should be
> definable by a couple of smart Mozillans in a couple of hours.

Agreed.

[Brian Smith]

Stephen Schultze wrote:
> On 10/16/12 4:59 AM, Rob Stradling wrote:
> > "(k) If certificate i is a version 3 certificate, verify that the
> > basicConstraints extension is present and that cA is set to
> > TRUE. (If certificate i is a version 1 or version 2
> > certificate, then the application MUST either verify that
> > certificate i is a CA certificate through out-of-band means
> > or reject the certificate. Conforming implementations may
> > choose to reject all version 1 and version 2 intermediate
> > certificates.)
> > ...If check...(k)...fails, the procedure terminates,
> > returning a failure indication and an appropriate reason."
>
> It seems to me that the proposed text simply adds a greater degree of
> specificity on top of RFC5280 and CABForum, which has been something
> that Mozilla has done across the board in the interest of its
> end-users.

Our proposed text says that we want every certificate that doesn't have isCA=false explicitly stated in the certificate to be disclosed. Rob's suggestion is that could get the intended effect by ensuring we refuse to accept certificates without an explicit isCA=true, and then saying that isCA=true (instead of the lack of isCA=false) is the way to identify CA certificates. This is a reasonable change to consider.

As far as v1 and v2 certificates, that is something that I think we want to discourage, because v1 and v2 lack the technical constraint features that this policy change is designed to encourage. This is one of the reasons that this change is worded the way it is. Another reason is that we suspect that v3 is the most interoperable format, and we want to promote interoperable and uniform processing of certificates. So, perhaps we will change the requirement to "must be x509v3 and has isCA set to true." Whether to require the extension to be critical is another thing that needs to be considered.

> > I think it would be useful to require the CAs that have their
> > certificate(s) included in Mozilla's CA Certificate Program to post
> > this information on their websites in some sort of standardized
> > format, so that it is not an insurmountable task for interested
> > parties to regularly retrieve and analyze all public disclosures.
>
> +1 to this, absolutely. In requiring this, we should avoid the
> pitfall of trying to create some new complicated spec that takes
> years to hash out. robots.txt could be inspiration, and the format
> should be definable by a couple of smart Mozillans in a couple of
> hours.

It would be convenient if the CA just maintains a tar.gz or ZIP file containing all of the (intermediate) DER-encoded certificates they have issued, at a specific URL. It would be great if we could put this as a requirement in the policy.

Cheers,
Brian

[Ryan Sleevi]

So while in terms of RFC 5280, the behaviour of basicConstraints is
exactly as Rob has described, in practice it has historically been less
than stellar. For reference, I point to [1] and [2], but regrettably must
share that I saw many more instances of the same bug in various forms in a
number of other, 'smaller' SSL and PKI libraries and bindings.

This is not and has not been a bug in Mozilla products, and thus is not
strictly necessary for Mozilla's immediate needs. However, as many
products - particularly whose limited size and scope does not allow them
to operate their own root programs - depend on the Mozilla CA Certificate
Policy for determining base trust lists, such a policy change provides a
technical constraint on otherwise buggy implementations.

The Baseline Requirements implicitly require all issued certificates be
X.509v3, by virtue of the fact that the Baseline Requirements require
basicConstraints on all Root & Subordinate CAs, and require subjectAltName
on all Subject Certificates. The requirement of extensions means the
version MUST be X.509v3 (or higher). Thus, the intended semantics of
basicConstraints, even when not asserted, MUST (or at least, are supposed
to) apply (RFC 5280, Section 6.1.4(k)).

If Mozilla is happy with the current language of BR + RFC 5280, and
willing to accept that such clients are buggy and thus out of scope of
Mozilla's proposed updates, then a proposed language change would be:

"A certificate is deemed as technically capable of issuing certificates if
it contains an X.509v3 basicConstraints extension, with the isCA boolean
set to true."

[1] http://support.apple.com/kb/HT4824
[2] http://www.thoughtcrime.org/ie-ssl-chain.txt

[Gervase Markham]

On 16/10/12 18:41, Ryan Sleevi wrote:
> If Mozilla is happy with the current language of BR + RFC 5280, and
> willing to accept that such clients are buggy and thus out of scope of
> Mozilla's proposed updates

If I understand you correctly, such buggy clients would consider almost
every end-entity certificate in the world today as a cert capable of
issuing further certificates, because they don't have isCA explicitly
set to false. This allows users of such a client to be MITMed for any
site by anyone for $0 if they can navigate a free CA's issuance process.

I would say that the magnitude and scope of that error would indeed
permit us to write off such a client as "buggy and out of scope" :-)

Gerv

[Kathleen Wilson]

On 10/15/12 3:26 PM, Kathleen Wilson wrote:
> To reiterate, the above text is proposed to replace what is currently in
> #9 of
> http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html.
>

I have not seen major concerns raised about this new text, so I have
updated the WorkInProgress page to make it easier for us to review and
edit. I have also incorporated some of the feedback from this discussion.

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

To do a side-by-side comparison of the new text versus the previous
text, scroll down to the bottom of the WorkInProgress page and click on
“Last modified…”. Diff between 110096 and 109374.
I have also posted previous versions of this item here:
https://wiki.mozilla.org/CA:CertPolicyUpdatesDrafts


Things that still need to be resolved (that I am aware of):

- Should I file a bug to have NSS refuse to accept intermediate
certificates that don't contain an X.509v3 basicConstraints extension
with the isCA boolean set to true?

- Figure out the rest of the text for the id-kp-codeSigning sub-bullet.

- Figure out if/what text should be added to specify the format for
disclosing intermediate certificates. (Would it be reasonable to say
tar.gz?)

- “If there are no such dNSNames (e.g. because the certificate is for
issuing IP-address-based certificates), then the certificate MUST
contain a dNSNames constraint that prohibits all DNS names.”
Is this statement clear? Does it need to link to a spec location where
this is explained? Where?

- Regarding Name Constraints, what about certificates that have the
hostname in the CN? Do we need to worry about this? I think NSS applies
name constraints to CN, https://bugzilla.mozilla.org/show_bug.cgi?id=394919.

- Should the wording about Name Constraints be updated to indicate that
a certificate is technically constrained IF it either possess these
extensions or is issued beneath such a constrained certificate? This is
the way libpkix works. (e.g. it's not necessary to repeat the
nameConstraints in every intermediate cert in the chain.)


Thanks,
Kathleen

[Eddy Nigg]

On 10/19/2012 12:12 AM, From Kathleen Wilson:

> - Should I file a bug to have NSS refuse to accept intermediate
> certificates that don't contain an X.509v3 basicConstraints extension
> with the isCA boolean set to true?

And why should it accept such a certificates as a CA exactly?

> - Figure out if/what text should be added to specify the format for
> disclosing intermediate certificates. (Would it be reasonable to say
> tar.gz?)

How about a certificates repository (URL)?

>
> - “If there are no such dNSNames (e.g. because the certificate is for
> issuing IP-address-based certificates), then the certificate MUST
> contain a dNSNames constraint that prohibits all DNS names.”
>

I'm not aware of such a thing. Simply no dnsName should be included in
that case (whereas an IP entry should be obviously used and not a
dnsName for the IP).

>
> - Regarding Name Constraints, what about certificates that have the
> hostname in the CN? Do we need to worry about this? I think NSS
> applies name constraints to CN,
> https://bugzilla.mozilla.org/show_bug.cgi?id=394919.

I think NSS should ignore any content in the common name entirely (host
names are not authoritative in the common name field).

>
> - Should the wording about Name Constraints be updated to indicate
> that a certificate is technically constrained IF it either possess
> these extensions or is issued beneath such a constrained certificate?

In my opinion yes.

[Kathleen Wilson]

On 10/18/12 3:47 PM, Eddy Nigg wrote:
> On 10/19/2012 12:12 AM, From Kathleen Wilson:
>> - Should I file a bug to have NSS refuse to accept intermediate
>> certificates that don't contain an X.509v3 basicConstraints extension
>> with the isCA boolean set to true?
>
> And why should it accept such a certificates as a CA exactly?
>

This was in response to the discussion about whether the text should be

"A certificate is deemed as technically capable of issuing certificates

if it contains an X.509v3 basicConstraints extension, with the isCA
boolean set to true."

instead of

"A certificate is deemed as technically capable of issuing certificates

if it lacks a critical X.509v3 basicConstraints extension with the isCA
boolean explicitly false."

What about the following text instead?

"A certificate is deemed as technically capable of issuing certificates

if it does not contain a basicConstraints extension, or contains an
X.509v3 basicConstraints extension with the isCA boolean set to true."

Or do we not need to worry about the case where the basicConstraints
extension is not set?

>> - Figure out if/what text should be added to specify the format for
>> disclosing intermediate certificates. (Would it be reasonable to say
>> tar.gz?)
>
> How about a certificates repository (URL)?

I don't know. The goal is that the certs be provided "in some sort of

standardized format, so that it is not an insurmountable task for
interested parties to regularly retrieve and analyze all public
disclosures."


>
>>

>> - “If there are no such dNSNames (e.g. because the certificate is for
>> issuing IP-address-based certificates), then the certificate MUST
>> contain a dNSNames constraint that prohibits all DNS names.”
>>
>
> I'm not aware of such a thing. Simply no dnsName should be included in
> that case (whereas an IP entry should be obviously used and not a
> dnsName for the IP).
>

So then the sentence:

"If there are no such dNSNames (e.g. because the certificate is for
issuing IP-address-based certificates), then the certificate MUST
contain a dNSNames constraint that prohibits all DNS names."

Should be changed to what?

>>
>> - Regarding Name Constraints, what about certificates that have the
>> hostname in the CN? Do we need to worry about this? I think NSS
>> applies name constraints to CN,
>> https://bugzilla.mozilla.org/show_bug.cgi?id=394919.
>
> I think NSS should ignore any content in the common name entirely (host
> names are not authoritative in the common name field).
>

So then we don't need to worry about this in the policy, just need to
make sure NSS moves to this behavior.

>>
>> - Should the wording about Name Constraints be updated to indicate
>> that a certificate is technically constrained IF it either possess
>> these extensions or is issued beneath such a constrained certificate?
>
> In my opinion yes.
>

Can someone please suggest ideas about what this text can be?


Thanks,
Kathleen

[Eddy Nigg]

On 10/19/2012 10:44 PM, From Kathleen Wilson:

> "A certificate is deemed as technically capable of issuing
> certificates if it does not contain a basicConstraints extension, or
> contains an X.509v3 basicConstraints extension with the isCA boolean
> set to true."

I wonder if NSS should accept a certificate without any basic
constraints these days. Doesn't the BR require those?

> I don't know. The goal is that the certs be provided "in some sort of
> standardized format, so that it is not an insurmountable task for
> interested parties to regularly retrieve and analyze all public
> disclosures."

In case of a public repository such as a directory listing or even a web
page with links to the certificates, tools like wget should be able to
fetch them all if necessary. Would that suffice? Of course an archive
will work too, but I would prefer to have more than one option.

>
> So then the sentence:
> "If there are no such dNSNames (e.g. because the certificate is for
> issuing IP-address-based certificates), then the certificate MUST
> contain a dNSNames constraint that prohibits all DNS names."
>
> Should be changed to what?

Maybe "If there are no such dNSNames (e.g. because the certificate is

for issuing IP-address-based certificates), then the certificate MUST

NOT contain any dNSNames.

But it seems to me not entirely clear what is to be achieved here. IP
addresses and host names can coexist in the SAN extensions. When there
are no host names defined (and only IP addresses) than no dnsNames will
appear in the SAN...

>
>> I think NSS should ignore any content in the common name entirely (host
>> names are not authoritative in the common name field).
>>
>
> So then we don't need to worry about this in the policy, just need to
> make sure NSS moves to this behavior.

Yes - client software that don't support the SAN extension have become
obsolete. I'm not ware of any common browser that doesn't supports it,
hence the common name field which was necessary in the 90's should be
ignored.

[Ryan Sleevi]

On Fri, October 19, 2012 3:58 pm, Eddy Nigg wrote:
> On 10/19/2012 10:44 PM, From Kathleen Wilson:

> > "A certificate is deemed as technically capable of issuing
> > certificates if it does not contain a basicConstraints extension, or
> > contains an X.509v3 basicConstraints extension with the isCA boolean
> > set to true."
>

> I wonder if NSS should accept a certificate without any basic
> constraints these days. Doesn't the BR require those?

For intermediates and roots, yes. For end-entity certs no.

However, according to Appendix B, the profile of certificate extensions
only specifies the requirements for Certificates generated after the
Effective Date.

The intent of deeming them capable of issuance here is to close the
ambiguity of X.509 v1/v2 (note, this is somewhat independent of what RFC
5280 says, which also leaves it ambiguous)

>
> > I don't know. The goal is that the certs be provided "in some sort of
> > standardized format, so that it is not an insurmountable task for
> > interested parties to regularly retrieve and analyze all public
> > disclosures."
>

> In case of a public repository such as a directory listing or even a web
> page with links to the certificates, tools like wget should be able to
> fetch them all if necessary. Would that suffice? Of course an archive
> will work too, but I would prefer to have more than one option.
>
> >

> > So then the sentence:
> > "If there are no such dNSNames (e.g. because the certificate is for
> > issuing IP-address-based certificates), then the certificate MUST
> > contain a dNSNames constraint that prohibits all DNS names."
> >
> > Should be changed to what?
>

> Maybe "If there are no such dNSNames (e.g. because the certificate is

> for issuing IP-address-based certificates), then the certificate MUST

> NOT contain any dNSNames.
>
> But it seems to me not entirely clear what is to be achieved here. IP
> addresses and host names can coexist in the SAN extensions. When there
> are no host names defined (and only IP addresses) than no dnsNames will
> appear in the SAN...

I believe the concern is that, as currently written, the language enforces
a restriction that prevents the *possibility* of misissuance under a
relevant name type.

Without the presence of the "Not good for any names", it's left to
application logic to make some determination as to whether the given name
type should be considered trustworthy, given the chain presented.

Consider an intermediate certificate issued to an enterprise CA that
specifies an iPAddress permittedSubtrees constraint that restricts it to
the organization's authorized (as assigned by the RIR like
ARIN/RIPE/APNIC/etc) IP space.

This client is "clearly" only authorized to issue certificates for
iPAddress SANs. These match the "technical constraints" section, so this
CA does not need to be disclosed. Now imagine this CA issues a certificate
with a dNSName of "www.google.com"

Under RFC5280 validation, such a certificate chain is valid (at least as
far as I read and interpret). 4.2.1.10. only requires that *constrained*
name types be rejected. This is highlighted in Section 8 (Security
Considerations), which states

In general, using the nameConstraints extension to constrain one name
form (e.g., DNS names) offers no protection against use of other name
forms (e.g., electronic mail addresses).

The current language closes this, by forcing the (NSS
supported/recognized) name types to be constrained, if the issuing CA does
not intend/authorized the subordinate to issue names of that type.

Under the BR (Section 9.2.1), the only subjectAltName name types that are
permitted are iPAddress and dNSName, so that's why the technical
constraints language requires both be present, and either explicitly say
"no names" or limit the names to the CA-validated namespaces.

>
> >
> >> I think NSS should ignore any content in the common name entirely (host
> >> names are not authoritative in the common name field).
> >>
> >
> > So then we don't need to worry about this in the policy, just need to
> > make sure NSS moves to this behavior.
>

> Yes - client software that don't support the SAN extension have become
> obsolete. I'm not ware of any common browser that doesn't supports it,
> hence the common name field which was necessary in the 90's should be
> ignored.

You're conflating two different issues. While "most" client software
supports sANs now (ignoring the vast majority of server-side processing
code that fails to support SANs or improperly supports wildcards), the
issue is the number of certificates issued without any sANs.

Unless and until every one of those "otherwise valid" certificates are
expired or revoked, the latter of which is not at all required under the
BR, then user agents must still be concerned with supporting them **when
no sAN is present**.

So no CA, issuing under the BR, should/will ever issue a leaf without a
sAN, so the discussion of nameConstraints is somewhat irrelevant. The only
place it applies is if, when CAs are adopting their infrastructure to
conform to the proposed requirements, and re-issuing enterprise
intermediate CAs to be technically constrained, that any **existing**
end-entity certs under those nodes remain as technically constrained as
any **new** certs (which will always have sANs)

This is the whole discussion of "legacy", which is on a different
timetable for CA issuance than it is for client support.

[Rob Stradling]

On 20/10/12 03:39, Ryan Sleevi wrote:
<snip>

> On Fri, October 19, 2012 3:58 pm, Eddy Nigg wrote:
>> On 10/19/2012 10:44 PM, From Kathleen Wilson:

<snip>

>>> So then the sentence:
>>> "If there are no such dNSNames (e.g. because the certificate is for
>>> issuing IP-address-based certificates), then the certificate MUST
>>> contain a dNSNames constraint that prohibits all DNS names."
>>>
>>> Should be changed to what?
>>

>> Maybe "If there are no such dNSNames (e.g. because the certificate is

>> for issuing IP-address-based certificates), then the certificate MUST

>> NOT contain any dNSNames.
>>
>> But it seems to me not entirely clear what is to be achieved here. IP
>> addresses and host names can coexist in the SAN extensions. When there
>> are no host names defined (and only IP addresses) than no dnsNames will
>> appear in the SAN...
>
> I believe the concern is that, as currently written, the language enforces
> a restriction that prevents the *possibility* of misissuance under a
> relevant name type.
>
> Without the presence of the "Not good for any names", it's left to
> application logic to make some determination as to whether the given name
> type should be considered trustworthy, given the chain presented.

Ryan,
How can a CA encode "Not good for any names" in a permittedSubtree or
excludedSubtree?

There must be at least 1 permittedSubtree or 1 excludedSubtree for each
name type, because otherwise (according to RFC5280)...
"If no name of the type is in the certificate, the certificate is
acceptable."
(Incidentally, "Not good for any names" is the default behaviour of
CryptoAPI on Windows XP (see [1] and [2]), but Vista and newer follow
RFC5280 correctly).

To prohibit all dNSNames, I can think of 2 options:
1. Include a dNSName permittedSubtree with a "dummy" domain name (e.g.
nodomainsarevalid.local)
or
2. Include a dNSName excludedSubtree with a zero-length dNSName. In
theory, this should cover all possible dNSNames, because RFC5280 says:
"Any DNS name that can be constructed by simply adding zero or more
labels to the left-hand side of the name satisfies the name constraint."
But putting a zero-length dNSName into a certificate seems like the sort
of thing that might break some unsuspecting software, so it'd definitely
be worth testing this!

[1] http://unmitigatedrisk.com/?p=198
[2] http://unmitigatedrisk.com/?p=201

> Consider an intermediate certificate issued to an enterprise CA that
> specifies an iPAddress permittedSubtrees constraint that restricts it to
> the organization's authorized (as assigned by the RIR like
> ARIN/RIPE/APNIC/etc) IP space.

The current draft of the policy update doesn't mention iPAddress
permittedSubtree or excludedSubtree constraints at all. I think it
should. If a technically constrained intermediate certificate (which
includes the id-kp-serverAuth extended key usage) is only permitted to
issue certs to dNSNames, then there should be a "Not good for any names"
iPAddress constraint.

How can a CA encode this? Again, I can think of 2 options:
1. Include an iPAddress permittedSubtree with a "dummy" IP address (e.g.
127.0.0.1)
or
2. Include 2 iPAddress excludedSubtree constraints, one which specifies
the entire IPv4 address range, and one which specifies the entire IPv6
address range.

<snip>

> Under the BR (Section 9.2.1), the only subjectAltName name types that are
> permitted are iPAddress and dNSName, so that's why the technical
> constraints language requires both be present, and either explicitly say
> "no names" or limit the names to the CA-validated namespaces.

As noted above, the current draft text doesn't mention iPAddress
constraints at all.

[Rob Stradling]

On 18/10/12 23:12, Kathleen Wilson wrote:
<snip>

> Things that still need to be resolved (that I am aware of):
>

> - Should I file a bug to have NSS refuse to accept intermediate

> certificates that don't contain an X.509v3 basicConstraints extension
> with the isCA boolean set to true?

Kathleen,

Nelson once wrote [1]...
"This bug annoys me, because there is no bug in NSS. This is invalid.
NSS has correctly honored basic constraints for over 12 years.
Way back when it was shown that MS Windows/IE ignored them completely,
and that anyone with an EE (Non-CA) cert could nonetheless use it like a
CA cert and issue subordinate certs that would be honored by IE, the NSS
team was shocked that anyone could get it so wrong.
We had gotten it right for years by then."

I don't think there's any need to file a new bug!

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=508355#c1

> - Figure out the rest of the text for the id-kp-codeSigning sub-bullet.

I suggest...

"If the certificate includes the id-kp-codeSigning extended key usage,
then the certificate MUST contain a directoryName permittedSubtrees
constraint where each permittedSubtree contains the organizationName,
localityName (where relevant), stateOrProvinceName (where relevant) and
countryName fields of an address that the issuing CA has confirmed
belongs to the subordinate CA."

> - Figure out if/what text should be added to specify the format for
> disclosing intermediate certificates. (Would it be reasonable to say
> tar.gz?)

Brian suggested that "the CA just maintains a tar.gz or ZIP file

containing all of the (intermediate) DER-encoded certificates they have

issued". I think that this would be insufficient, because the draft
policy update also requires disclosure of...

- The corresponding Certificate Policy or Certification Practice

Statement used by the subordinate CA; and

- Annual public attestation of conformance to the stated certificate
verification requirements and other operational criteria by a competent
independent party or parties with access to the details of the
subordinate CA's internal operations.

How about defining a simple XML (or JSON) schema?

> - “If there are no such dNSNames (e.g. because the certificate is for
> issuing IP-address-based certificates), then the certificate MUST
> contain a dNSNames constraint that prohibits all DNS names.”
> Is this statement clear? Does it need to link to a spec location where
> this is explained? Where?

This statement is not clear to me. See the other message I posted
earlier today.

> - Regarding Name Constraints, what about certificates that have the
> hostname in the CN? Do we need to worry about this? I think NSS applies
> name constraints to CN,
> https://bugzilla.mozilla.org/show_bug.cgi?id=394919.

Yes, according to that bug, NSS (both libpkix and the old pre-libpkix
code) already applies dNSName constraints to the CN field.

That bug also mentions IP addresses in the CN field, but it's not clear
to me what the current NSS behaviour is.

> - Should the wording about Name Constraints be updated to indicate that
> a certificate is technically constrained IF it either possess these

> extensions or is issued beneath such a constrained certificate? This is
> the way libpkix works. (e.g. it's not necessary to repeat the
> nameConstraints in every intermediate cert in the chain.)

No! IMHO, the fact that it is "issued beneath such a constrained
certificate" is irrelevant. A non-constrained certificate chain for the
same issuing CA Name/Key might also exist already, or it might exist in
the future!

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

[Ryan Sleevi]

On Mon, October 22, 2012 4:31 am, Rob Stradling wrote:
<snip>

> Ryan,
> How can a CA encode "Not good for any names" in a permittedSubtree or
> excludedSubtree?
>
> There must be at least 1 permittedSubtree or 1 excludedSubtree for each
> name type, because otherwise (according to RFC5280)...
> "If no name of the type is in the certificate, the certificate is
> acceptable."
> (Incidentally, "Not good for any names" is the default behaviour of
> CryptoAPI on Windows XP (see [1] and [2]), but Vista and newer follow
> RFC5280 correctly).
>
> To prohibit all dNSNames, I can think of 2 options:
> 1. Include a dNSName permittedSubtree with a "dummy" domain name (e.g.
> nodomainsarevalid.local)
> or
> 2. Include a dNSName excludedSubtree with a zero-length dNSName. In
> theory, this should cover all possible dNSNames, because RFC5280 says:
> "Any DNS name that can be constructed by simply adding zero or more
> labels to the left-hand side of the name satisfies the name constraint."
> But putting a zero-length dNSName into a certificate seems like the sort
> of thing that might break some unsuspecting software, so it'd definitely
> be worth testing this!

Correct. I believe Option 2 is what the policy means to suggest as the
viable constraint. Note that "nodomainsarevalid.local" is not, in fact, a
dummy domain - just a name in an as-yet-unallocated gTLD - which is part
of why Option 2 is preferable.

> The current draft of the policy update doesn't mention iPAddress
> permittedSubtree or excludedSubtree constraints at all. I think it
> should. If a technically constrained intermediate certificate (which
> includes the id-kp-serverAuth extended key usage) is only permitted to
> issue certs to dNSNames, then there should be a "Not good for any names"
> iPAddress constraint.
>
> How can a CA encode this? Again, I can think of 2 options:
> 1. Include an iPAddress permittedSubtree with a "dummy" IP address (e.g.
> 127.0.0.1)
> or
> 2. Include 2 iPAddress excludedSubtree constraints, one which specifies
> the entire IPv4 address range, and one which specifies the entire IPv6
> address range.

Here again, Option 2 is/was the intended method.

>
> <snip>
> > Under the BR (Section 9.2.1), the only subjectAltName name types that
> > are
> > permitted are iPAddress and dNSName, so that's why the technical
> > constraints language requires both be present, and either explicitly say
> > "no names" or limit the names to the CA-validated namespaces.
>
> As noted above, the current draft text doesn't mention iPAddress
> constraints at all.

Yes, this was a point I had raised prior to the publication as a "known
issue" with the current draft text.

My selfishly individual preference for the handling of least privilege
here would be through the use of application-specific verification logic,
to know whether or not the certificate is considered "valid" for issuing
names of such a type (eg: either that there is a certificate in the chain
with a constrained name of that type, or that all the intermediates are
publicly disclosed, however that is measured), simply because I fear the
additional overhead involved with having to repeatedly issue certificates
with excludedSubtrees that prevent the world.

It also has a feel of trying to blacklist "known" name types, rather than
whitelist. As a security measure, blacklists tend to fail quite often in
practice, which is why I'm not optimistic.

One possible solution to the above problem was/is to implement a whitelist
extension, where constraints are listed, and any name not constrained is
not valid, but that would potentially open a host of other issues with
compatibility.

One concern that exists with both the application-logic and the
whitelist-extension approach is that they do not offer constraints for
"legacy" applications. Thus if one could compromise such an intermediate,
then while they could not issue certificates that would be valid under
current/new Mozilla products, any existing RFC5280 (or earlier) products
would happily accept the certificate.

Marking the extension as "critical" is a way to break such backwards
compatibility - but as we've seen with nameConstraints themselves, the
notion of requiring a break to backwards compatibility is a hard pill to
swallow.

For these reasons, this is why I would prefer the "application-defined"
whitelisting mechanism as to what the application sees as permitted names
types.

[Ryan Sleevi]

On Mon, October 22, 2012 6:09 am, Rob Stradling wrote:
> On 18/10/12 23:12, Kathleen Wilson wrote:
<snip>
>

> > - Should the wording about Name Constraints be updated to indicate that
> > a certificate is technically constrained IF it either possess these
> > extensions or is issued beneath such a constrained certificate? This is
> > the way libpkix works. (e.g. it's not necessary to repeat the
> > nameConstraints in every intermediate cert in the chain.)
>
> No! IMHO, the fact that it is "issued beneath such a constrained
> certificate" is irrelevant. A non-constrained certificate chain for the
> same issuing CA Name/Key might also exist already, or it might exist in
> the future!
>

Rob,

Wouldn't such a chain be considered a violation of the Mozilla Root
Inclusion Policy?

I suspect that there may need to be some clarifying text here (and I also
highlighted this as an issue), but if any subordinate-or-root CA issued a
certificate that would cause the current subordinate to be unconstrained,
it would seem like a violation. The language to work out mostly revolves
around "issuance", and that "issuance" applies both at the time of minting
the (subordinate) certificate, as well as any refreshes on the (issuing)
certificate that change the effective semantics.

So if (issuing) CA was technically constrained, and then re-issued as
non-technically constrained, it would seem like every (existing)
subordinate-or-leaf under that CA had been re-issued.

To be honest, I'm not entirely sure how this would be retroactively
audited, and it may be that the solution is to simply that such reissuance
would be (effectively) prevented by policy, rather than trying to carve up
the right language.

Note that this would only apply to the "publicly trusted" roots in Mozilla
(eg: as added as part of the program). Thus, an organization could always
create a cross-signed certificate with the same name & public key, and in
a way that made the subordinate effectively unconstrained, and I would
think that would be "acceptable", in the sense that enterprise trust
anchors are out of scope for the proposed policy.

My biggest concern with requiring that constraints be redundantly
enumerated on every subordinate - besides being wholly unnecessary in
terms of RFC 5280 - is that it adds a non-trivial overhead per-certificate
to express this. As mentioned in your other mail, if every certificate
would need to have excludedSubtrees for IPv4 and IPv6 iPAddresses, then
that provides a real disincentive for subordinate CAs to further delegate
names. For example, an mit.edu nameConstrained subordinate may wish to
separate out into staff.mit.edu and students.mit.edu, and then perhaps
compsci.staff.mit.edu and compsci.students.mit.edu, delegating
responsibility for issuance at each level. With redundant nameConstraints,
there is technically unnecessary added cost for such delegation.

I'd have to defer to the CAs here to know what sort of enterprise
intermediates already exist, since this is presently opaque data, and to
how common or long such chains typically are. Such enterprise chains
rarely make it on to the public Internet, since their typical value is
primarily internal-only, and it may be again that here the policy
language, as currently written, effectively prohibits/discourages this.

[Kathleen Wilson]

On 10/22/12 6:09 AM, Rob Stradling wrote:
>
>> - Figure out the rest of the text for the id-kp-codeSigning sub-bullet.
>
> I suggest...
>
> "If the certificate includes the id-kp-codeSigning extended key usage,
> then the certificate MUST contain a directoryName permittedSubtrees
> constraint where each permittedSubtree contains the organizationName,
> localityName (where relevant), stateOrProvinceName (where relevant) and
> countryName fields of an address that the issuing CA has confirmed
> belongs to the subordinate CA."

I copied this text into the corresponding sub-bullet in
www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html

Thanks!
Kathleen

[Rob Stradling]

On 22/10/12 16:33, Ryan Sleevi wrote:
> On Mon, October 22, 2012 4:31 am, Rob Stradling wrote:
> <snip>

>> To prohibit all dNSNames, I can think of 2 options:
>> 1. Include a dNSName permittedSubtree with a "dummy" domain name (e.g.
>> nodomainsarevalid.local)
>> or
>> 2. Include a dNSName excludedSubtree with a zero-length dNSName. In
>> theory, this should cover all possible dNSNames, because RFC5280 says:
>> "Any DNS name that can be constructed by simply adding zero or more
>> labels to the left-hand side of the name satisfies the name constraint."
>> But putting a zero-length dNSName into a certificate seems like the sort
>> of thing that might break some unsuspecting software, so it'd definitely
>> be worth testing this!
>
> Correct. I believe Option 2 is what the policy means to suggest as the
> viable constraint. Note that "nodomainsarevalid.local" is not, in fact, a
> dummy domain - just a name in an as-yet-unallocated gTLD - which is part
> of why Option 2 is preferable.

Agreed, so I suggest clarifying this by changing...

"If there are no such dNSNames (e.g. because the certificate is for
issuing IP-address-based certificates), then the certificate MUST
contain a dNSNames constraint that prohibits all DNS names."

...to something like...

"If there are no such dNSNames (e.g. because the certificate is for
issuing IP-address-based certificates), then the certificate MUST

contain a zero-length dNSName excludedSubtree constraint."

And, as I mentioned before, I really think we need to test that this
works before the policy is finalized!

>> The current draft of the policy update doesn't mention iPAddress
>> permittedSubtree or excludedSubtree constraints at all. I think it
>> should. If a technically constrained intermediate certificate (which
>> includes the id-kp-serverAuth extended key usage) is only permitted to
>> issue certs to dNSNames, then there should be a "Not good for any names"
>> iPAddress constraint.
>>
>> How can a CA encode this? Again, I can think of 2 options:
>> 1. Include an iPAddress permittedSubtree with a "dummy" IP address (e.g.
>> 127.0.0.1)
>> or
>> 2. Include 2 iPAddress excludedSubtree constraints, one which specifies
>> the entire IPv4 address range, and one which specifies the entire IPv6
>> address range.
>
> Here again, Option 2 is/was the intended method.

OK.

<snip>

>> As noted above, the current draft text doesn't mention iPAddress
>> constraints at all.
>
> Yes, this was a point I had raised prior to the publication as a "known
> issue" with the current draft text.
>
> My selfishly individual preference for the handling of least privilege
> here would be through the use of application-specific verification logic,
> to know whether or not the certificate is considered "valid" for issuing
> names of such a type (eg: either that there is a certificate in the chain
> with a constrained name of that type, or that all the intermediates are
> publicly disclosed, however that is measured), simply because I fear the
> additional overhead involved with having to repeatedly issue certificates
> with excludedSubtrees that prevent the world.

Why would there be a need "to repeatedly issue certificates with
excludedSubtrees that prevent the world" ?

> It also has a feel of trying to blacklist "known" name types, rather than
> whitelist. As a security measure, blacklists tend to fail quite often in
> practice, which is why I'm not optimistic.

If new name types were added often, I would agree. But how many
different name types are actually used with server authentication today?

> One possible solution to the above problem was/is to implement a whitelist
> extension, where constraints are listed, and any name not constrained is
> not valid, but that would potentially open a host of other issues with
> compatibility.
>
> One concern that exists with both the application-logic and the
> whitelist-extension approach is that they do not offer constraints for
> "legacy" applications. Thus if one could compromise such an intermediate,
> then while they could not issue certificates that would be valid under
> current/new Mozilla products, any existing RFC5280 (or earlier) products
> would happily accept the certificate.
>
> Marking the extension as "critical" is a way to break such backwards
> compatibility - but as we've seen with nameConstraints themselves, the
> notion of requiring a break to backwards compatibility is a hard pill to
> swallow.
>
> For these reasons, this is why I would prefer the "application-defined"
> whitelisting mechanism as to what the application sees as permitted names
> types.

Mozilla has an "application-defined" whitelisting mechanism for
constraining the types of certificate that an intermediate certificate
can issue: the netscapeCertType extension. But rather than use this,
the consensus is to use the EKU extension in an RFC5280-non-compliant
manner. Why? Because the EKU proposal is more widely supported in
existing and legacy platforms.

So I can't see Mozilla opting for an "application-defined" whitelisting
mechanism for "permitted name types" when the alternative solution -
blacklisting using name constraints - is far more widely supported in
existing and legacy platforms.

[Rob Stradling]

On 22/10/12 16:52, Ryan Sleevi wrote:
> On Mon, October 22, 2012 6:09 am, Rob Stradling wrote:
>> On 18/10/12 23:12, Kathleen Wilson wrote:
> <snip>
>>
>>> - Should the wording about Name Constraints be updated to indicate that
>>> a certificate is technically constrained IF it either possess these
>>> extensions or is issued beneath such a constrained certificate? This is
>>> the way libpkix works. (e.g. it's not necessary to repeat the
>>> nameConstraints in every intermediate cert in the chain.)
>>
>> No! IMHO, the fact that it is "issued beneath such a constrained
>> certificate" is irrelevant. A non-constrained certificate chain for the
>> same issuing CA Name/Key might also exist already, or it might exist in
>> the future!
>>
>
> Rob,
>
> Wouldn't such a chain be considered a violation of the Mozilla Root
> Inclusion Policy?

Ryan, that's a good point. I'll change my answer to Kathleen's question
to "Yes".

> I suspect that there may need to be some clarifying text here (and I
> also highlighted this as an issue), but if any subordinate-or-root CA
> issued a certificate that would cause the current subordinate to be
> unconstrained, it would seem like a violation.

If the intermediate certificate(s) below the
reissued-without-constraints intermediate remain non-publicly-disclosed
and non-audited, then yes, I agree that it would be a violation of the
2.1 draft policy.

But I can imagine that there might be cases where name constraints are
employed initially, but after some time it becomes apparent that this is
too inflexible for the subordinate CA's needs. So I think it should be
permitted for a CA to have their intermediate certificate reissued
without constraints so that the CA can move from technically constrained
to publicly disclosed/audited.

<snip>

[Ryan Sleevi]

On Mon, October 22, 2012 1:24 pm, Rob Stradling wrote:
> > I suspect that there may need to be some clarifying text here (and I
> > also highlighted this as an issue), but if any subordinate-or-root CA
> > issued a certificate that would cause the current subordinate to be
> > unconstrained, it would seem like a violation.
>
> If the intermediate certificate(s) below the
> reissued-without-constraints intermediate remain non-publicly-disclosed
> and non-audited, then yes, I agree that it would be a violation of the
> 2.1 draft policy.
>
> But I can imagine that there might be cases where name constraints are
> employed initially, but after some time it becomes apparent that this is
> too inflexible for the subordinate CA's needs. So I think it should be
> permitted for a CA to have their intermediate certificate reissued
> without constraints so that the CA can move from technically constrained
> to publicly disclosed/audited.

Agreed, and perhaps I should have worded it from "cause the current
subordinate to be unconstrained" to "cause the current subordinate to be
non-compliant with the policy"

Am I mistaken in thinking that transitioning from a constrained
intermediate to an unconstrained intermediate would require
revocation-or-audit-scope-and-disclosure of all intermediates issued by
the originally constrained intermediate?

If you remove the constraints from one level, they would need to shift to
the next level, and that would mean any intermediates previously issued
would need to either be constrained or part of the same audit scope. In
particular, this concerns me, because under the constrained scenario,
there are no audit requirements, thus it may not be clear how many
unconstrained intermediates were issued by the constrained cert. In order
to actively assert that all certificates under the unconstrained cert are,
in fact, constrained, you would need to have good proof of them, and I
think that will be an issue.

So perhaps the transition from constrained -> unconstrained is one that
cannot (securely) happen in practice? Am I missing something?

[Kathleen Wilson]

On 10/18/12 3:12 PM, Kathleen Wilson wrote:
>
> http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html
>
> Item #9
>
> To do a side-by-side comparison of the new text versus the previous
> text, scroll down to the bottom of the WorkInProgress page and click on
> “Last modified…”.
>

Thanks to all of you who are actively participating in this discussion!

Here is the list of current issues to be resolved, and (based on my
understanding of the discussions) my thoughts/questions about how to
move forward.

1) "A certificate is deemed as technically capable of issuing
certificates if it *does not contain a basicConstraints extension, or*
contains an X.509v3 basicConstraints extension with the isCA boolean set
to true."

Since we're moving towards requiring all root and intermediate certs to
have basicConstraints, then let's not add text to the policy that gives
the impression that it's OK to have intermediate certs without
basicConstraints.

Rather than adding the
“does not contain a basicConstraints extension” part,
is there something else to exclude end-entity certs? (e.g.
pathLenConstraint?)


2) Figure out if/what text should be added to specify the format for
disclosing intermediate certificates.

I think we should move forward without specifying this in the policy for
now, and just add a section to
https://wiki.mozilla.org/CA:Recommended_Practices to list the ways the
certs may be disclosed. (e.g. certificate repository, web page
listing/linking-to the certs, archive file like tar.gz, etc).


3) Improve: “If there are no such dNSNames (e.g. because the certificate

is for issuing IP-address-based certificates), then the certificate MUST
contain a dNSNames constraint that prohibits all DNS names.”

Rob Stradling's recommended text: "If there are no such dNSNames (e.g.

because the certificate is for issuing IP-address-based certificates),

then the certificate MUST contain a zero-length dNSName excludedSubtree
constraint."
*With caveat: And, as I mentioned before, I really think we need to test
that this works before the policy is finalized!*

Are there any volunteers for doing this test?


4) Regarding Name Constraints, what about certificates that have the

hostname in the CN? Do we need to worry about this? I think NSS applies
name constraints to CN, https://bugzilla.mozilla.org/show_bug.cgi?id=394919.

There are legacy certs that have the hostname in the CN and not in the
SAN. According to BR 9.2.2 domain name (or IP address) must be in the
SAN (can *also* be in subject CN, but discouraged).

I think we should close this issue and not try to add text about it to
the proposed subCA policy. Let's let it be handled via the BRs and NSS
code.


5) Should the wording about Name Constraints be updated to indicate that

a certificate is technically constrained IF it either possess these
extensions or is issued beneath such a constrained certificate? This is
the way libpkix works. (e.g. it's not necessary to repeat the
nameConstraints in every intermediate cert in the chain.)

The answer is Yes.
Any suggestions about how to change the text to address this?


Thanks,
Kathleen

[Eddy Nigg]

On 10/23/2012 08:12 PM, From Kathleen Wilson:

> 3) Improve: “If there are no such dNSNames (e.g. because the
> certificate is for issuing IP-address-based certificates), then the
> certificate MUST contain a dNSNames constraint that prohibits all DNS
> names.”
>
> Rob Stradling's recommended text: "If there are no such dNSNames (e.g.
> because the certificate is for issuing IP-address-based certificates),
> then the certificate MUST contain a zero-length dNSName
> excludedSubtree constraint."
> *With caveat: And, as I mentioned before, I really think we need to
> test that this works before the policy is finalized!*
>
>

If you ask me, this will not give you any protection (specially not from
a runaway CA) - instead I suggest to do perhaps controversial thing and
against the RFC and not trust any server certificates without a dnsName.
This should be handled at the client software, the BR already supports
it in my opinion without having to add anything.

> 4) Regarding Name Constraints, what about certificates that have the
> hostname in the CN? Do we need to worry about this? I think NSS
> applies name constraints to CN,
> https://bugzilla.mozilla.org/show_bug.cgi?id=394919.
>
> There are legacy certs that have the hostname in the CN and not in the
> SAN. According to BR 9.2.2 domain name (or IP address) must be in the
> SAN (can *also* be in subject CN, but discouraged).
>
> I think we should close this issue and not try to add text about it to
> the proposed subCA policy. Let's let it be handled via the BRs and NSS
> code.

Same here, leave the BR and Mozilla policy as is and change NSS and PSM
to ignore the CN.

[Rob Stradling]

On 22/10/12 22:58, Ryan Sleevi wrote:
> On Mon, October 22, 2012 1:24 pm, Rob Stradling wrote:
>> > I suspect that there may need to be some clarifying text here (and I
>> > also highlighted this as an issue), but if any subordinate-or-root CA
>> > issued a certificate that would cause the current subordinate to be
>> > unconstrained, it would seem like a violation.
>>
>> If the intermediate certificate(s) below the
>> reissued-without-constraints intermediate remain non-publicly-disclosed
>> and non-audited, then yes, I agree that it would be a violation of the
>> 2.1 draft policy.
>>
>> But I can imagine that there might be cases where name constraints are
>> employed initially, but after some time it becomes apparent that this is
>> too inflexible for the subordinate CA's needs. So I think it should be
>> permitted for a CA to have their intermediate certificate reissued
>> without constraints so that the CA can move from technically constrained
>> to publicly disclosed/audited.
>
> Agreed, and perhaps I should have worded it from "cause the current
> subordinate to be unconstrained" to "cause the current subordinate to be
> non-compliant with the policy"
>
> Am I mistaken in thinking that transitioning from a constrained
> intermediate to an unconstrained intermediate would require
> revocation-or-audit-scope-and-disclosure of all intermediates issued by
> the originally constrained intermediate?

You're not mistaken.

> If you remove the constraints from one level, they would need to shift to
> the next level, and that would mean any intermediates previously issued
> would need to either be constrained or part of the same audit scope.

Yes.

> In particular, this concerns me, because under the constrained scenario,
> there are no audit requirements, thus it may not be clear how many
> unconstrained intermediates were issued by the constrained cert. In order
> to actively assert that all certificates under the unconstrained cert are,
> in fact, constrained, you would need to have good proof of them, and I
> think that will be an issue.
>
> So perhaps the transition from constrained -> unconstrained is one that
> cannot (securely) happen in practice? Am I missing something?

In theory, the auditor could make a judgement about whether or not there
is "good proof" that the transition has been done, or could be done,
securely.

But in practice, each audit only looks back at (typically) the previous
year's worth of CA activity, so if the constrained-and-unaudited
intermediate had been used for >1 year before the CA decided that they
wanted to switch to being
unconstrained-and-publicly-disclosed-and-audited, it's fairly likely
that the auditor would refuse to pass the audit.

[Rob Stradling]

On 23/10/12 19:12, Kathleen Wilson wrote:
<snip>

> Thanks to all of you who are actively participating in this discussion!

Happy to help. :-)

> Here is the list of current issues to be resolved, and (based on my
> understanding of the discussions) my thoughts/questions about how to
> move forward.
>
> 1) "A certificate is deemed as technically capable of issuing
> certificates if it *does not contain a basicConstraints extension, or*
> contains an X.509v3 basicConstraints extension with the isCA boolean set
> to true."
>
> Since we're moving towards requiring all root and intermediate certs to
> have basicConstraints, then let's not add text to the policy that gives
> the impression that it's OK to have intermediate certs without
> basicConstraints.

RFC5280 (and its predecessors RFC3280 and RFC2459) says that all CA
certificates MUST contain the basicConstraints extension and that it
MUST be marked critical. Therefore, any certificate that lacks the
basicConstraints extension is an end-entity certificate.

In other words, it's completely impossible "to have intermediate certs

without basicConstraints".

> Rather than adding the
> “does not contain a basicConstraints extension” part,
> is there something else to exclude end-entity certs? (e.g.
> pathLenConstraint?)

The statement "A certificate is deemed as technically capable of issuing
certificates if it does not contain a basicConstraints extension" is
just plain wrong!

<snip>
> 3) Improve: “If there are no such dNSNames (e.g. because the certificate

> is for issuing IP-address-based certificates), then the certificate MUST
> contain a dNSNames constraint that prohibits all DNS names.”
>

> Rob Stradling's recommended text: "If there are no such dNSNames (e.g.

> because the certificate is for issuing IP-address-based certificates),

> then the certificate MUST contain a zero-length dNSName excludedSubtree
> constraint."
> *With caveat: And, as I mentioned before, I really think we need to test
> that this works before the policy is finalized!*
>

> Are there any volunteers for doing this test?

I'm happy to do this testing. I should be able to do it within the next
couple of weeks.

<snip>

[Erwann Abalea]

Le mercredi 24 octobre 2012 17:33:47 UTC+2, Rob Stradling a écrit :
> On 23/10/12 19:12, Kathleen Wilson wrote:

[...]

> > 1) "A certificate is deemed as technically capable of issuing
> > certificates if it *does not contain a basicConstraints extension, or*
> > contains an X.509v3 basicConstraints extension with the isCA boolean set
> > to true."
>
> > Since we're moving towards requiring all root and intermediate certs to
> > have basicConstraints, then let's not add text to the policy that gives
> > the impression that it's OK to have intermediate certs without
> > basicConstraints.

Strictly speaking, the basicConstraints extension is not necessary for a root. It's not clearly worded like this in X.509 or RFC5280 but can be derived from:
- a trust anchor is not necessarily a certificate (that's just more convenient)
- the trust anchor is not part of the certificates considered when following the validation algorithm (in which certificates are checked, and basicConstraints extension is verified)

> RFC5280 (and its predecessors RFC3280 and RFC2459) says that all CA
> certificates MUST contain the basicConstraints extension and that it
> MUST be marked critical. Therefore, any certificate that lacks the
> basicConstraints extension is an end-entity certificate.

The wording is different in X.509, but in paragraph 8.4.2.1 (basicConstraints) there's the following note:

NOTE 1 – If this extension is not present, or is flagged non-critical and is not recognized by a certificate-using system, then the certificate is to be considered an end-entity certificate and cannot be used to verify certificate signatures.

> In other words, it's completely impossible "to have intermediate certs
> without basicConstraints".

I fully agree.

[Rob Stradling]

On 23/10/12 19:32, Eddy Nigg wrote:
> On 10/23/2012 08:12 PM, From Kathleen Wilson:

>> 3) Improve: “If there are no such dNSNames (e.g. because the
>> certificate is for issuing IP-address-based certificates), then the
>> certificate MUST contain a dNSNames constraint that prohibits all DNS
>> names.”
>>
>> Rob Stradling's recommended text: "If there are no such dNSNames (e.g.
>> because the certificate is for issuing IP-address-based certificates),
>> then the certificate MUST contain a zero-length dNSName
>> excludedSubtree constraint."
>> *With caveat: And, as I mentioned before, I really think we need to
>> test that this works before the policy is finalized!*
>

> If you ask me, this will not give you any protection (specially not from
> a runaway CA) - instead I suggest to do perhaps controversial thing and
> against the RFC and not trust any server certificates without a dnsName.
> This should be handled at the client software, the BR already supports
> it in my opinion without having to add anything.

Hi Eddy. Unless you're proposing that CAs MUST NOT issue certificates
where the SAN->iPAddress field is present and the SAN->dNSName field is
omitted, I think you've completely misunderstood the context of this issue.

[Eddy Nigg]

On 10/25/2012 11:12 AM, From Rob Stradling:

Well, if there is no SAN extension present, the certificate shouldn't be
trusted for server certificates.

The SAN extension is required to my understanding and you can't really
"distrust" actively dnsNames, it also wouldn't be complaint to the BR
because it requires validated entries.

If the SAN is present with an IP entry, I believe the software is
required to trust only this. Or did I really misunderstand the issue?

[Rob Stradling]

On 26/10/12 22:15, Eddy Nigg wrote:
> On 10/25/2012 11:12 AM, From Rob Stradling:

> Well, if there is no SAN extension present, the certificate shouldn't be
> trusted for server certificates.
>
> The SAN extension is required to my understanding and you can't really
> "distrust" actively dnsNames, it also wouldn't be complaint to the BR
> because it requires validated entries.
>
> If the SAN is present with an IP entry, I believe the software is
> required to trust only this. Or did I really misunderstand the issue?

Hi Eddy. You're correct that the SAN extension is required in
end-entity certificates (according to the Baseline Requirements), but
that's not the issue we're discussing here.

This issue is about how to use Name Constraints to lock down an
Intermediate Certificate so that the issued end-entity certs may contain
1 or more SAN->iPAddress fields but _not_ contain any SAN->dNSName fields.

[Kathleen Wilson]

On 10/23/12 11:12 AM, Kathleen Wilson wrote:
> Here is the list of current issues to be resolved, and (based on my
> understanding of the discussions) my thoughts/questions about how to
> move forward.
>
> 1) "A certificate is deemed as technically capable of issuing
> certificates if it *does not contain a basicConstraints extension, or*
> contains an X.509v3 basicConstraints extension with the isCA boolean set
> to true."
>
> Since we're moving towards requiring all root and intermediate certs to
> have basicConstraints, then let's not add text to the policy that gives
> the impression that it's OK to have intermediate certs without
> basicConstraints.
>
> Rather than adding the
> “does not contain a basicConstraints extension” part,
> is there something else to exclude end-entity certs? (e.g.
> pathLenConstraint?)
>

Closing this item as no-action.

As Rob pointed out: "RFC5280 (and its predecessors RFC3280 and RFC2459)

says that all CA certificates MUST contain the basicConstraints
extension and that it MUST be marked critical. Therefore, any
certificate that lacks the basicConstraints extension is an end-entity
certificate."

And Erwann pointed out: "...but in paragraph 8.4.2.1 (basicConstraints)

there's the following note: NOTE 1 – If this extension is not present,
or is flagged non-critical and is not recognized by a certificate-using
system, then the certificate is to be considered an end-entity
certificate and cannot be used to verify certificate signatures."

I updated
http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html
to fix the terminology to match RFC5280: “A certificate is deemed as

technically capable of issuing certificates if it contains an X.509v3

basicConstraints extension, with the *cA boolean* set to true.”

>
> 2) Figure out if/what text should be added to specify the format for
> disclosing intermediate certificates.
>
> I think we should move forward without specifying this in the policy for
> now, and just add a section to
> https://wiki.mozilla.org/CA:Recommended_Practices to list the ways the
> certs may be disclosed. (e.g. certificate repository, web page
> listing/linking-to the certs, archive file like tar.gz, etc).
>

Thinking about this more... If we have a list of urls pointing to tar.gz
and .zip files, then we could potentially have software that
automatically checks them for updates. So maybe it would be a good idea
to add to the part about publicly disclosed DER-encoded X.509
certificates to say that they should be provided in either a tar.gz or
..zip file?

>
> 3) Improve: “If there are no such dNSNames (e.g. because the certificate
> is for issuing IP-address-based certificates), then the certificate MUST
> contain a dNSNames constraint that prohibits all DNS names.”
>
> Rob Stradling's recommended text: "If there are no such dNSNames (e.g.
> because the certificate is for issuing IP-address-based certificates),
> then the certificate MUST contain a zero-length dNSName excludedSubtree
> constraint."
> *With caveat: And, as I mentioned before, I really think we need to test
> that this works before the policy is finalized!*
>
> Are there any volunteers for doing this test?
>

Rob volunteered to test this.

Another possibility is to simply just not allow IP addresses in SSL
certs chaining up to roots in Mozilla's CA program.

>
> 4) Regarding Name Constraints, what about certificates that have the
> hostname in the CN? Do we need to worry about this? I think NSS applies
> name constraints to CN,
> https://bugzilla.mozilla.org/show_bug.cgi?id=394919.
>
> There are legacy certs that have the hostname in the CN and not in the
> SAN. According to BR 9.2.2 domain name (or IP address) must be in the
> SAN (can *also* be in subject CN, but discouraged).
>
> I think we should close this issue and not try to add text about it to
> the proposed subCA policy. Let's let it be handled via the BRs and NSS
> code.
>

On a slightly different topic...

Should we be more specific about what is allowed in permittedSubtrees?

Such as:
“If the certificate includes the id-kp-serverAuth extended key usage,
then the certificate MUST include the Name Constraints X.509v3
extension. The Name Constraints extension MUST contain a dNSName
permittedSubtrees constraint that only contains domains for which the
issuing CA has confirmed that the subordinate CA has registered or has
been authorized by the domain registrant to act on the registrant's
behalf. *Each entry in the dNSName permittedSubtrees constraint must end
with a TLD (including the dot) listed in the IANA root zone database
(links to http://www.iana.org/domains/root/db/). For example,
example.com would be an acceptable constraint entry, but all of the
following are not acceptable: .com, examplecom, localhost, mail,
example.local, .local.*"

>
> 5) Should the wording about Name Constraints be updated to indicate that
> a certificate is technically constrained IF it either possess these
> extensions or is issued beneath such a constrained certificate? This is
> the way libpkix works. (e.g. it's not necessary to repeat the
> nameConstraints in every intermediate cert in the chain.)
>
> The answer is Yes.
> Any suggestions about how to change the text to address this?

I have not been able to find a way to phrase this that doesn't open up a
bunch of holes. I propose that we leave the requirement for Name
Constraints at every level. Could the performance concerns about this be
dealt with by decreasing the number of intermediate certs in the chain?

6) Concerns raised about there being delay to accept new
disclosed/audited intermediate certs.

This would clearly have to be worked out before a white-list mechanism
can be released. But I think we can still move forward with the policy
update.

A new intermediate cert can start out as being technically constrained,
and then when it is accepted it can be transitioned to non-technically
constrained by regenerating the intermediate cert to remove the
technical constraints. Correct?


Thanks,
Kathleen

[Steve Roylance]

Hi Kathleen - In line concerning IP addresses.

On 14/11/2012 22:32, "Kathleen Wilson" <kwi...@mozilla.com> wrote:

>
>>
>> 3) Improve: ³If there are no such dNSNames (e.g. because the certificate
>> is for issuing IP-address-based certificates), then the certificate MUST
>> contain a dNSNames constraint that prohibits all DNS names.²
>>
>> Rob Stradling's recommended text: "If there are no such dNSNames (e.g.
>> because the certificate is for issuing IP-address-based certificates),
>> then the certificate MUST contain a zero-length dNSName excludedSubtree
>> constraint."
>> *With caveat: And, as I mentioned before, I really think we need to test
>> that this works before the policy is finalized!*
>>
>> Are there any volunteers for doing this test?
>>
>
>Rob volunteered to test this.
>
>Another possibility is to simply just not allow IP addresses in SSL
>certs chaining up to roots in Mozilla's CA program.

GlobalSign, along with Digicert and Opera is currently rewording a
proposal to the Baseline Requirements around SubjectAlternativeNames that
will assert best practice for certificates with IP Addresses. I do not
think we need to remove this capability as it's a valuable tool. We
simply need to ensure consistency of the rules CAs follow such that
subject identity information can be included when IP addresses are present
(Given that there's no layman's WHOIS method to identify the owner).

We hope to have the text ready later today or early tomorrow to help with
some of the previous feedback on this subject.

[Eddy Nigg]

On 11/15/2012 01:41 PM, From Steve Roylance:

> We simply need to ensure consistency of the rules CAs follow such that
> subject identity information can be included when IP addresses are
> present (Given that there's no layman's WHOIS method to identify the
> owner).

Just in case you didn't know:

[rwhois.liquidweb.com]
%rwhois V-1.5:003eff:00 rwhois.liquidweb.com (by Network Solutions,
Inc. V-1.5.7.4)
network:Class-Name:network
network:ID:NETBLK-GLOBALSIGN.67.225.200.82/32
network:Auth-Area:67.225.128.0/17
network:Network-Name:GLOBALSIGN-67.225.200.82
network:IP-Network:67.225.200.82/32
network:IP-Network-Block:67.225.200.82-67.225.200.82
network:Organization;I:GLOBALSIGN
network:Org-Name:Globalsign
network:Street-Address:Two International Drive Suite 105
network:City:Portsmouth
network:State:NH
network:Postal-Code:03081
network:Country-Code:US
network:Tech-Contact;I:denni...@globalsign.com
network:Abuse:ab...@sourcedns.com
network:Created:20121115
network:Updated:20121115
network:Updated-By:ad...@sourcedns.com

Should be probably taken into account.

[Rob Stradling]

On 14/11/12 22:32, Kathleen Wilson wrote:
> On 10/23/12 11:12 AM, Kathleen Wilson wrote:

>> Here is the list of current issues to be resolved, and (based on my
>> understanding of the discussions) my thoughts/questions about how to
>> move forward.

<snip>

>> 3) Improve: “If there are no such dNSNames (e.g. because the certificate
>> is for issuing IP-address-based certificates), then the certificate MUST
>> contain a dNSNames constraint that prohibits all DNS names.”
>>
>> Rob Stradling's recommended text: "If there are no such dNSNames (e.g.
>> because the certificate is for issuing IP-address-based certificates),
>> then the certificate MUST contain a zero-length dNSName excludedSubtree
>> constraint."
>> *With caveat: And, as I mentioned before, I really think we need to test
>> that this works before the policy is finalized!*
>>
>> Are there any volunteers for doing this test?
>

> Rob volunteered to test this.

Hi Kathleen. I've setup a test site here...

https://alldnsnamesexcludedtest.comodoca.com

I've tested this with as many browsers as I have access to, and all of
those that support Name Constraints treat the zero-length dNSName
excludedSubtree constraint correctly. :-)

[Kathleen Wilson]

Rob, Thank you for doing this testing!

So then the last sentence of the 4th sub-bullet of #9 should be changed
as follows:

"If the certificate includes the id-kp-serverAuth extended key usage,
then the certificate MUST include the Name Constraints X.509v3
extension. The Name Constraints extension MUST contain a dNSName
permittedSubtrees constraint that only contains domains for which the
issuing 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 there are no such dNSNames (e.g. because the certificate is

for issuing IP-address-based certificates), then the certificate MUST
contain a zero-length dNSName excludedSubtree constraint."

Correct?

Thanks,
Kathleen

[Rob Stradling]

On 29/11/12 00:10, Kathleen Wilson wrote:
<snip>

>> I've tested this with as many browsers as I have access to, and all of
>> those that support Name Constraints treat the zero-length dNSName
>> excludedSubtree constraint correctly. :-)
>>
>

> Rob, Thank you for doing this testing!

Hi Kathleen. Happy to help. :-)

> So then the last sentence of the 4th sub-bullet of #9 should be changed
> as follows:
>
> "If the certificate includes the id-kp-serverAuth extended key usage,
> then the certificate MUST include the Name Constraints X.509v3
> extension. The Name Constraints extension MUST contain a dNSName
> permittedSubtrees constraint that only contains domains for which the
> issuing 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 there are no such dNSNames (e.g. because the certificate is

> for issuing IP-address-based certificates), then the certificate MUST
> contain a zero-length dNSName excludedSubtree constraint."
>

> Correct?

Yes, making that change would be an improvement.

However, while this covers dNSName constraints sufficiently, I think (as
discussed in other messages in this thread) we also need to constrain
the iPAddress field as far as possible too.

So here's my attempt at rewording that sub-bullet:

"If the certificate includes the id-kp-serverAuth extended key usage,
then the certificate MUST include the Name Constraints X.509v3 extension

with constraints on both dNSName and iPAddress.
If the certificate will never issue to dNSNames, then it MUST include a
zero-length dNSName in excludedSubtrees. Otherwise, permittedSubtrees
MUST include one or more dNSNames which the issuing 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 certificate will never issue to iPAddresses, then it MUST specify
the entire IPv4 and IPv6 address ranges in excludedSubtrees. Otherwise,
permittedSubtrees MUST include one or more iPAddress ranges which the
issuing CA has confirmed that the subordinate CA has been assigned or
has been authorized by the assigner to act on the assignee's behalf."

I think it would be useful to hear what Brian and Ryan think of this
proposed text.

[Kathleen Wilson]

On 11/29/12 3:40 AM, Rob Stradling wrote:
> "If the certificate includes the id-kp-serverAuth extended key usage,
> then the certificate MUST include the Name Constraints X.509v3 extension
> with constraints on both dNSName and iPAddress.
> If the certificate will never issue to dNSNames, then it MUST include a
> zero-length dNSName in excludedSubtrees. Otherwise, permittedSubtrees
> MUST include one or more dNSNames which the issuing 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 certificate will never issue to iPAddresses, then it MUST specify
> the entire IPv4 and IPv6 address ranges in excludedSubtrees. Otherwise,
> permittedSubtrees MUST include one or more iPAddress ranges which the
> issuing CA has confirmed that the subordinate CA has been assigned or
> has been authorized by the assigner to act on the assignee's behalf."
>

I think this text needs to be re-organized, but I have a few questions
before I attempt it...

1) Would it be reasonable to require a separate intermediate certificate
for issuance of ip-address-based certs?

2) Another thing we had wanted to add is: "Each entry in the dNSName

permittedSubtrees constraint must end with a TLD (including the dot)

listed in the IANA root zone database <links to
http://www.iana.org/domains/root/db/>. For example, example.com would be

an acceptable constraint entry, but all of the following are not
acceptable: .com, examplecom, localhost, mail, example.local, .local.*"

IP Addressed based certs was not the original focus of this bullet
point. I am wondering if we can have the main bullet point be about
dNSNames, and then have an exception (a sub-bullet point) for ip addresses.


3)

> If the certificate will never issue to iPAddresses, then it MUST specify
> the entire IPv4 and IPv6 address ranges in excludedSubtrees.

How is this done?


4)

> issuing CA has confirmed that the subordinate CA has been assigned or
> has been authorized by the assigner to act on the assignee's behalf."

This is very confusing to me. I apologize for my ignorance when it comes
to IP address based SSL certs... Who assigns the IP addresses?


Thanks,
Kathleen

[Ryan Sleevi]

On Mon, December 3, 2012 1:07 pm, Kathleen Wilson wrote:
> On 11/29/12 3:40 AM, Rob Stradling wrote:

> > "If the certificate includes the id-kp-serverAuth extended key usage,
> > then the certificate MUST include the Name Constraints X.509v3 extension
> > with constraints on both dNSName and iPAddress.
> > If the certificate will never issue to dNSNames, then it MUST include a
> > zero-length dNSName in excludedSubtrees. Otherwise, permittedSubtrees
> > MUST include one or more dNSNames which the issuing 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 certificate will never issue to iPAddresses, then it MUST specify
> > the entire IPv4 and IPv6 address ranges in excludedSubtrees. Otherwise,
> > permittedSubtrees MUST include one or more iPAddress ranges which the
> > issuing CA has confirmed that the subordinate CA has been assigned or
> > has been authorized by the assigner to act on the assignee's behalf."
> >
>
>

> I think this text needs to be re-organized, but I have a few questions
> before I attempt it...
>
> 1) Would it be reasonable to require a separate intermediate certificate
> for issuance of ip-address-based certs?

This would (effectively) prevent issuing both name-based and IP-based
certificates from the same hierarchy. Is that intended?

>
> 2) Another thing we had wanted to add is: "Each entry in the dNSName
> permittedSubtrees constraint must end with a TLD (including the dot)
> listed in the IANA root zone database <links to
> http://www.iana.org/domains/root/db/>. For example, example.com would be
> an acceptable constraint entry, but all of the following are not
> acceptable: .com, examplecom, localhost, mail, example.local, .local.*"
>
> IP Addressed based certs was not the original focus of this bullet
> point. I am wondering if we can have the main bullet point be about
> dNSNames, and then have an exception (a sub-bullet point) for ip
> addresses.
>
>
> 3)

> > If the certificate will never issue to iPAddresses, then it MUST specify
> > the entire IPv4 and IPv6 address ranges in excludedSubtrees.
>

> How is this done?

A NameConstraints extension that, within the excludedSubtrees SEQUENCE,
has a GeneralSubtrees that has a GeneralName base with an iPAddress of 8
octets, 00 00 00 00 00 00 00 00 (matching the CIDR notation of 0.0.0.0/0,
or the address 0.0.0.0 with a subnet mask of 0.0.0.0). That matches the
IPv4 space. Additionally, a GeneralName base with an iPAddress of 32
octets, containing 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 (matching the notation of ::0
with a prefix of /0 )

>
>
> 4)

> > issuing CA has confirmed that the subordinate CA has been assigned or
> > has been authorized by the assigner to act on the assignee's behalf."
>
>

> This is very confusing to me. I apologize for my ignorance when it comes
> to IP address based SSL certs... Who assigns the IP addresses?

There are five Regional Internet Registries (RIR) that are assigned
address ranges by IANA. The RIRs, in turn, follow RIR-defined policies to
delegate addresses to customers.

For example, this mail was sent by mailman2.corp.phx1.mozilla.com
[63.245.216.66]. By going to http://whois.iana.org, I can look up
63.245.216.66 and see that it has been assigned to ARIN. By going to
http://whois.arin.net and entering 63.245.216.66, I can see that the
address belongs to the CIDR 63.245.208.0/20, which has been assigned to
Mozilla Corporation via Direct Assignment.

Looking up the information for the Mozilla Corporation record via ARIN's
whois (which is handily hotlinked from that page), I can see an address on
file for Mozilla, including the technical, administrative, and abuse
contact information.

As you can see, the iPAddress pool is very similar to DNS in terms of what
information is provided - offering equivalent security as DV certificates.

Note that these addresses differ than the reserved addresses (
http://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xml
,
http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml
), which are deprecated according to the Baseline Requirements, similar to
intranet (hostless) domains.

[Stephen Schultze]

On 10/22/12 9:09 AM, Rob Stradling wrote:
>
>> - Figure out if/what text should be added to specify the format for
>> disclosing intermediate certificates. (Would it be reasonable to say
>> tar.gz?)
>
> Brian suggested that "the CA just maintains a tar.gz or ZIP file
> containing all of the (intermediate) DER-encoded certificates they have
> issued". I think that this would be insufficient, because the draft
> policy update also requires disclosure of...
> - The corresponding Certificate Policy or Certification Practice
> Statement used by the subordinate CA; and
> - Annual public attestation of conformance to the stated certificate
> verification requirements and other operational criteria by a competent
> independent party or parties with access to the details of the
> subordinate CA's internal operations.
>
> How about defining a simple XML (or JSON) schema?

I am torn because that seems too complicated. I like the simplicity of
the .tgz file.

On the other hand, you could define an XML/JSON schema as you suggest --
but do so quickly and require deployment in very short order.

I do not like Kathleen's currently proposed text:
"The Certificate Policy or Certification Practice Statement of the CA
that has their certificate included in Mozilla's CA Certificate Program
must specify where on that CA's website all such public disclosures are
located."

This is not sufficiently machine-readable to serve the original purpose
for which the requirement was envisioned (ie: easy automated checking of
all roots).

Time to get this done.

[Kathleen Wilson]

On 12/3/12 9:19 PM, Ryan Sleevi wrote:
> On Mon, December 3, 2012 1:07 pm, Kathleen Wilson wrote:
>> On 11/29/12 3:40 AM, Rob Stradling wrote:
>>> "If the certificate includes the id-kp-serverAuth extended key usage,
>>> then the certificate MUST include the Name Constraints X.509v3 extension
>>> with constraints on both dNSName and iPAddress.
>>> If the certificate will never issue to dNSNames, then it MUST include a
>>> zero-length dNSName in excludedSubtrees. Otherwise, permittedSubtrees
>>> MUST include one or more dNSNames which the issuing 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 certificate will never issue to iPAddresses, then it MUST specify
>>> the entire IPv4 and IPv6 address ranges in excludedSubtrees. Otherwise,
>>> permittedSubtrees MUST include one or more iPAddress ranges which the
>>> issuing CA has confirmed that the subordinate CA has been assigned or
>>> has been authorized by the assigner to act on the assignee's behalf."
>>>
>>
>>
>> I think this text needs to be re-organized, but I have a few questions
>> before I attempt it...
>>
>> 1) Would it be reasonable to require a separate intermediate certificate
>> for issuance of ip-address-based certs?
>
> This would (effectively) prevent issuing both name-based and IP-based
> certificates from the same hierarchy. Is that intended?
>

That's what I was thinking, but maybe it's too extreme?
(My personal preference is to not allow IP addresses in certs chaining
up to roots in NSS, but that's not the direction that these discussions
have taken.)

Here is my understanding. Please correct.

- The Name Constraints X.509v3 extension MUST have permittedSubtrees,
and permittedSubtrees may be a combination of dNSNames and iPAddress
ranges.

- For each dNSName in permittedSubtrees, the issuing CA MUST confirm
that the subordinate CA has registered the dNSName or has been

authorized by the domain registrant to act on the registrant's behalf.

Each dNSName in permittedSubtrees must end with a TLD (including the

dot) listed in the IANA root zone database <links to
http://www.iana.org/domains/root/db/>. For example, example.com would be
an acceptable constraint entry, but all of the following are not
acceptable: .com, examplecom, localhost, mail, example.local, .local.*

- For each iPAddress range in permittedSubtrees, the issuing CA MUST
confirm that the subordinate CA has been assigned the iPAddress range or
has been authorized by the assigner to act on the assignee's behalf. (Is
that the best way to phrase this? Will it be clear to everyone what this
means?)

- If the subCA is not allowed to issue certs with dNSNames, then the
subCA cert MUST include a zero-length dNSName in excludedSubtrees.

- If the subCA is not allowed to issue certs with iPAddress ranges, then
the subCA cert MUST specify the entire IPv4 and IPv6 address ranges in
excludedSubtrees. (Is this the correct way to say it? Will it be clear
to everyone what needs to be in the cert?)

>>
>> 2) Another thing we had wanted to add is: "Each entry in the dNSName
>> permittedSubtrees constraint must end with a TLD (including the dot)
>> listed in the IANA root zone database <links to
>> http://www.iana.org/domains/root/db/>. For example, example.com would be
>> an acceptable constraint entry, but all of the following are not
>> acceptable: .com, examplecom, localhost, mail, example.local, .local.*"
>>
>> IP Addressed based certs was not the original focus of this bullet
>> point. I am wondering if we can have the main bullet point be about
>> dNSNames, and then have an exception (a sub-bullet point) for ip
>> addresses.
>>
>>
>> 3)
>>> If the certificate will never issue to iPAddresses, then it MUST specify
>>> the entire IPv4 and IPv6 address ranges in excludedSubtrees.
>>
>> How is this done?
>
> A NameConstraints extension that, within the excludedSubtrees SEQUENCE,
> has a GeneralSubtrees that has a GeneralName base with an iPAddress of 8
> octets, 00 00 00 00 00 00 00 00 (matching the CIDR notation of 0.0.0.0/0,
> or the address 0.0.0.0 with a subnet mask of 0.0.0.0). That matches the
> IPv4 space. Additionally, a GeneralName base with an iPAddress of 32
> octets, containing 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 (matching the notation of ::0
> with a prefix of /0 )
>

So is the proposed text clear, or should it look more like the following?

- If the subCA is not allowed to issue certs with iPAddress ranges, then
the subCA cert MUST include a NameConstraints extension that, within the

excludedSubtrees SEQUENCE, has a GeneralSubtrees that has a GeneralName

base with an iPAddress of 8 octets matching the CIDR notation of
0.0.0.0/0, and the address 0.0.0.0 with a subnet mask of 0.0.0.0).

Thanks for the explanation.

Thanks,
Kathleen

[Kathleen Wilson]

>>> On 11/29/12 3:40 AM, Rob Stradling wrote:
>>>> "If the certificate includes the id-kp-serverAuth extended key usage,
>>>> then the certificate MUST include the Name Constraints X.509v3
>>>> extension
>>>> with constraints on both dNSName and iPAddress.
>>>> If the certificate will never issue to dNSNames, then it MUST include a
>>>> zero-length dNSName in excludedSubtrees. Otherwise, permittedSubtrees
>>>> MUST include one or more dNSNames which the issuing 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 certificate will never issue to iPAddresses, then it MUST
>>>> specify
>>>> the entire IPv4 and IPv6 address ranges in excludedSubtrees.
>>>> Otherwise,
>>>> permittedSubtrees MUST include one or more iPAddress ranges which the
>>>> issuing CA has confirmed that the subordinate CA has been assigned or
>>>> has been authorized by the assigner to act on the assignee's behalf."
>>>>

I have updated #9 of
http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html

to reflect this proposal, but I re-organized the text based on my
understanding.

Please re-review the entire proposed #9 text (using the link), paying
special attention to the bullet points regarding SSL (serverAuth) certs.

Please also double check the technical accuracy of the proposed text.

Thanks,
Kathleen

[Ryan Sleevi]

On Fri, December 7, 2012 12:09 pm, Kathleen Wilson wrote:
> >>> On 11/29/12 3:40 AM, Rob Stradling wrote:
> >>>> "If the certificate includes the id-kp-serverAuth extended key usage,
> >>>> then the certificate MUST include the Name Constraints X.509v3
> >>>> extension
> >>>> with constraints on both dNSName and iPAddress.
> >>>> If the certificate will never issue to dNSNames, then it MUST include
> >>>> a
> >>>> zero-length dNSName in excludedSubtrees. Otherwise,
> >>>> permittedSubtrees
> >>>> MUST include one or more dNSNames which the issuing 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 certificate will never issue to iPAddresses, then it MUST
> >>>> specify
> >>>> the entire IPv4 and IPv6 address ranges in excludedSubtrees.
> >>>> Otherwise,
> >>>> permittedSubtrees MUST include one or more iPAddress ranges which the
> >>>> issuing CA has confirmed that the subordinate CA has been assigned or
> >>>> has been authorized by the assigner to act on the assignee's behalf."
> >>>>
>
>
>

> I have updated #9 of
> http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html
>
> to reflect this proposal, but I re-organized the text based on my
> understanding.
>
> Please re-review the entire proposed #9 text (using the link), paying
> special attention to the bullet points regarding SSL (serverAuth) certs.
>
> Please also double check the technical accuracy of the proposed text.
>

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

The proposed text currently only covers IPv4 addresses.

"If the subordinate CA is not allowed to issue certificates with an
iPAddress, then the subordinate CA certificate MUST specify the entire

IPv4 and IPv6 address ranges in excludedSubtrees.

* The subordinate CA certificate MUST include within excludedSubtree an
iPAddress GeneralName of 8 zero octets (covering the IPv4 address range
of 0.0.0.0/0)
* The subordinate CA certificate MUST include within excludedSubtrees an
iPAddress GeneralName of 32 zero octets (covering the IPv6 address range
of ::0/0)"

[Rob Stradling]

On 07/12/12 20:26, Ryan Sleevi wrote:
<snip>

> The proposed text currently only covers IPv4 addresses.
>
> "If the subordinate CA is not allowed to issue certificates with an

> iPAddress, then the subordinate CA certificate MUST specify the entire

> IPv4 and IPv6 address ranges in excludedSubtrees.

> * The subordinate CA certificate MUST include within excludedSubtree an
> iPAddress GeneralName of 8 zero octets (covering the IPv4 address range
> of 0.0.0.0/0)
> * The subordinate CA certificate MUST include within excludedSubtrees an
> iPAddress GeneralName of 32 zero octets (covering the IPv6 address range
> of ::0/0)"

Also Kathleen, I think the second "or" in "...it MUST contain one or
more dNSName or iPAddress permittedSubtrees constraints..." would mean
that a subordinate certificate could contain 1 iPAddress
permittedSubtree, no dNSName constraints at all (meaning any domain name
can be issued to), but still be regarded as technically constrained.
I'm pretty sure you'll agree that this is an unintended loophole!

In contrast, my proposed text explicitly closed this loophole by stating
"both" instead of "or"...
"...the certificate MUST include the Name Constraints X.509v3 extension

with constraints on both dNSName and iPAddress."

[Rob Stradling]

On 07/12/12 20:09, Kathleen Wilson wrote:
<snip>

> I have updated #9 of
> http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html
>
> to reflect this proposal, but I re-organized the text based on my
> understanding.
>
> Please re-review the entire proposed #9 text (using the link), paying
> special attention to the bullet points regarding SSL (serverAuth) certs.
>
> Please also double check the technical accuracy of the proposed text.

Hi Kathleen. Regarding this bit...
"Each dNSName in permittedSubtrees must end with a top-level domain
(TLD) listed in the IANA root zone database. For example, example.com

would be an acceptable constraint entry, but all of the following are

not acceptable: .com, examplecom, localhost, mail, .local.*, example.local."

This would mean that co.uk is an acceptable constraint entry, but I'd be
surprised if this is what you intended.

How about stating instead that each dNSName in permittedSubtrees must be
a registrable domain (with zero or more subdomains) according to the
Public Suffix List algorithm?

[Kathleen Wilson]

On 12/7/12 12:26 PM, Ryan Sleevi wrote:
> "If the subordinate CA is not allowed to issue certificates with an
> iPAddress, then the subordinate CA certificate MUST specify the entire
> IPv4 and IPv6 address ranges in excludedSubtrees.
> * The subordinate CA certificate MUST include within excludedSubtree an
> iPAddress GeneralName of 8 zero octets (covering the IPv4 address range
> of 0.0.0.0/0)
> * The subordinate CA certificate MUST include within excludedSubtrees an
> iPAddress GeneralName of 32 zero octets (covering the IPv6 address range
> of ::0/0)"

Fixed.

Thanks!
Kathleen

[Kathleen Wilson]

I updated the text again. Does that solve the problem?

Thanks,
Kathleen

[Kathleen Wilson]

Updated the text to:
"Each dNSName in permittedSubtrees must be a registrable domain (with
zero or more subdomains) according to the Public Suffix List algorithm."

Is the link that I used for "Public Suffix List algorithm" the correct one?

Does this new text need any further clarification?

Thanks,
Kathleen

[Peter Kurrasch]

Hi Kathleen--

I'd like to offer the following feedback on this latest version of item
#9 on the policy. I am concerned that item 9 is too unwieldy as-is and,
therefore, unenforceable. My intention is to be constructive here--and
I hope that comes through.

(1) Can we split this item 9 into two parts? I like that the rest of
the policy statement is written from a "we require" or "we consider"
point of view and I think it would help to see that here.

My specific recommendation is that part one say: "We prefer that
certificates which are technically capable of issuing other certificates
also include technical constraints that limit the application/use of
subordinate certs in a given certificate chain." Perhaps there is a
better wording, but the idea is just to say "we prefer technical
constraints instead of the publicly disclosed route". Of course maybe
I'm making an assumption that there is such a preference?

Further, my recommendation is that part two say: "We recognize that
technically constraining certs is not practical or possible for all
cases, and in those cases we require that such certs be publicly
disclosed and audited."


(2) I'm not a fan of requirements without enforcements, so I'm
hoping/assuming here that Mozilla products will enforce the technical
constraints in real-time. Is that a valid assumption? If so, I think
the policy should also state "we will" or "we reserve the right to" fail
cert/chain validation if the technical constraints are not met in real-time.

I guess I would emphasize that here we are talking about "future
consequences" of behavior whereas the rest of the policy doc is more of
a "rules for joining the club".


(3) For the non-technically-constrained case, I don't understand why
Mozilla cares about the format in which the certs are disclosed. If
Mozilla's only concern is that anyone and everyone is able to view them
then I would suggest the list of .p7c, .zip, .tgz, etc. be provided as
just an example. Would Mozilla ever choose to bundle these
publicly-disclosed certs with any of its products?

If, on the other hand, the expectation is that software will somehow be
reviewing the list in quasi-real-time then I have major concerns about
the formatting. By saying that software will grab a .zip or .tgz (or
xml or der or whatever) we're also saying that the client code must
implement all of those compression schemes and parsers and so forth. I
think that's a whole level of complexity that is best avoided. Instead
I would say .p7c is the only supported format.

(BTW--is it okay to call them intermediate certs? If so let's use that
term since "certificate-issuing certificates" can get a little crazy.)


I'll leave it there for now. Thanks!

On 12.07.2012 2:09 PM, Kathleen Wilson wrote:
> I have updated #9 of
> http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html
>
> to reflect this proposal, but I re-organized the text based on my
> understanding.
>
> Please re-review the entire proposed #9 text (using the link), paying
> special attention to the bullet points regarding SSL (serverAuth) certs.
>
> Please also double check the technical accuracy of the proposed text.
>

> Thanks,
> Kathleen

[Ryan Sleevi]

The technical constraints described within the proposed text make use of
the standard RFC 3280/5280 path validation algorithm. This algorithm is
implemented in the "new" (~2004) certificate validation library [libpkix]
in NSS (which is what Firefox & Thunderbird [all platforms] and Chromium
for Linux/ChromeOS/iOS use). Additionally, the constraints
described/support for RFC 3280/5280 are implemented by a variety of other
products outside of the Mozilla program - most notably, all products using
Microsoft Windows' CryptoAPI (Chromium for Windows, Internet Explorer,
Safari for Windows)

If any of these browsers encounter a certificate that was issued by a
constrained intermediate, but does not comply with the constraints of the
intermediate, they will hard fail.

So yeah, there is definitely "real-time" enforcement going on here, for
all standards-supporting clients (eg: not just Mozilla clients)

>
>
> (3) For the non-technically-constrained case, I don't understand why
> Mozilla cares about the format in which the certs are disclosed. If
> Mozilla's only concern is that anyone and everyone is able to view them
> then I would suggest the list of .p7c, .zip, .tgz, etc. be provided as
> just an example. Would Mozilla ever choose to bundle these
> publicly-disclosed certs with any of its products?
>
> If, on the other hand, the expectation is that software will somehow be
> reviewing the list in quasi-real-time then I have major concerns about
> the formatting. By saying that software will grab a .zip or .tgz (or
> xml or der or whatever) we're also saying that the client code must
> implement all of those compression schemes and parsers and so forth. I
> think that's a whole level of complexity that is best avoided. Instead
> I would say .p7c is the only supported format.

If by "client" code you mean end user browsers - no, I do not believe that
is the intent.

If by "client" code you mean tools written by Mozilla or Chromium
developers to audit their programs, or by third parties such as EFF,
academics, etc - then yes, I believe that is the intent. And as such,
supporting a variety of formats and compression schemes is not a
significant burden, so long as it's well-defined what are the *possible*
values. This is an area where I suspect "CA preference" is perfectly
acceptable, provided it's constrained to a bounded set of options.

Regardless, I suspect that such work is further away than the more
pressing needs of updating Mozilla's policy to require the Baseline
Requirements and address concerns regarding unconstrained intermediates.
The issue of format and structure of disclosure can come at a later time,
and I suspect that members of the Mozilla development community and of the
wider security community are willing to accept and deal with such formats
by hand, and update the Mozilla policy at a later point to provide more
structured guidance on this matter.

>
> (BTW--is it okay to call them intermediate certs? If so let's use that
> term since "certificate-issuing certificates" can get a little crazy.)
>
>
> I'll leave it there for now. Thanks!
>
>
>
> On 12.07.2012 2:09 PM, Kathleen Wilson wrote:
> > I have updated #9 of
> > http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html
> >
> > to reflect this proposal, but I re-organized the text based on my
> > understanding.
> >
> > Please re-review the entire proposed #9 text (using the link), paying
> > special attention to the bullet points regarding SSL (serverAuth) certs.
> >
> > Please also double check the technical accuracy of the proposed text.
> >

[Kathleen Wilson]

On 12/7/12 9:43 PM, Ryan Sleevi wrote:
> On Fri, December 7, 2012 5:17 pm, Peter Kurrasch wrote:
>> Hi Kathleen--
>>
>> I'd like to offer the following feedback on this latest version of item
>> #9 on the policy. I am concerned that item 9 is too unwieldy as-is and,
>> therefore, unenforceable. My intention is to be constructive here--and
>> I hope that comes through.
>>
>> (1) Can we split this item 9 into two parts? I like that the rest of
>> the policy statement is written from a "we require" or "we consider"
>> point of view and I think it would help to see that here.
>>
>> My specific recommendation is that part one say: "We prefer that
>> certificates which are technically capable of issuing other certificates
>> also include technical constraints that limit the application/use of
>> subordinate certs in a given certificate chain." Perhaps there is a
>> better wording, but the idea is just to say "we prefer technical
>> constraints instead of the publicly disclosed route". Of course maybe
>> I'm making an assumption that there is such a preference?
>>
>> Further, my recommendation is that part two say: "We recognize that
>> technically constraining certs is not practical or possible for all
>> cases, and in those cases we require that such certs be publicly
>> disclosed and audited."
>>

I think there is merit in separating the currently proposed #9 to make
it easier to work with. e.g We can separate the "technically
constrained" rules into a #10, and separate the "publicly disclosed and
audited" rules into a #11.

It would look like the following:
~~
9. All certificates that are technically capable of issuing
certificates, and which directly or transitively chain to a certificate
included in Mozilla's CA Certificate Program, MUST be operated in
accordance with Mozilla's CA Certificate Policy and MUST either be
technically constrained or be publicly disclosed and audited.
- A certificate is deemed as technically capable of issuing certificates
if it contains an X.509v3 basicConstraints extension, with the cA
boolean set to true. The term "subordinate CA" below refers to any
organization or legal entity that is in possession or control of a
certificate that is technically capable of issuing certificates.
- These requirements include all cross-certified certificates which
chain to a certificate that is included in Mozilla's CA Certificate
Program.

10. We encourage CAs to technically constrain all subordinate CA
certificates. For a certificate to be considered technically
constrained, the certificate MUST include an Extended Key Usage (EKU)
extension specifying all extended key usages that the subordinate CA is
authorized to issue certificates for. The anyExtendedKeyUsage
KeyPurposeId MUST NOT appear within this extension.
....<related bullet points>

11. We recognize that technically constraining subordinate CA
certificates as described above may not be practical for all cases.
All certificates that are technically capable of issuing certificates,
that are not technically constrained, and that directly or transitively
chain to a certificate included in Mozilla's CA Certificate Program MUST
be publicly disclosed by the CA that has their certificate included in
Mozilla's CA Certificate Program. The CA with a certificate included in
Mozilla's CA Certificate Program MUST disclose this information before
any such subordinate CA is allowed to issue certificates. All disclosure
MUST be made freely available and without additional requirements,
including, but not limited to, registration, legal agreements, or
restrictions on redistribution of the certificates in whole or in part.

The Certificate Policy or Certification Practice Statement of the CA
that has their certificate included in Mozilla's CA Certificate Program
must specify where on that CA's website all such public disclosures are

located. For a certificate to be considered publicly disclosed and
audited, the following information MUST be provided:
.... <related bullet points>
~~


Are there any objections to this change?

Thanks,
Kathleen

[Kathleen Wilson]

>> On Fri, December 7, 2012 5:17 pm, Peter Kurrasch wrote:
>>> Hi Kathleen--
>>>
>>> I'd like to offer the following feedback on this latest version of
>>> item
>>> #9 on the policy. I am concerned that item 9 is too unwieldy as-is
>>> and,
>>> therefore, unenforceable. My intention is to be constructive
>>> here--and
>>> I hope that comes through.
>>>
>>> (1) Can we split this item 9 into two parts? I like that the rest of
>>> the policy statement is written from a "we require" or "we consider"
>>> point of view and I think it would help to see that here.
>
>

> I think there is merit in separating the currently proposed #9 to make
> it easier to work with. e.g We can separate the "technically
> constrained" rules into a #10, and separate the "publicly disclosed and
> audited" rules into a #11.
>

I have made the change in
http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html
See items #9, 10, and 11.

Also note that in the new item #11 I added the following text to the
second sentence:
"MUST be audited in accordance with Mozilla's CA Certificate Policy"

It may be redundant, but it seemed necessary after I separated the
proposed policy into separate items.

Please do one more careful review of the proposed policy.

If we think this is about ready, then I'll submit this version for legal
review.

Thanks,
Kathleen

PS: To see diffs of the changes scroll down to the bottom of the page
and click on "Last modified on..."

[Eddy Nigg]

On 12/10/2012 09:44 PM, From Kathleen Wilson:

>
> Please do one more careful review of the proposed policy.
>
>

I just noticed during a quick read:

..../a certificate that is *technically* capable of issuing certificates/
shows up a couple of times.

I believe that the word /*technically*/ is not necessary. A CA
certificates can't issue a certificate technically or non-technically.
It may be technically constrained, but it can either issue or not.

I personally wonder how you'd enforce that a certificate is either
technically constrained *OR* publicly disclosed and audited. It seems to
me not really enforceable, but that's probably something you already
discussed. To me it looks like a red herring.

[Kathleen Wilson]

On 12/10/12 12:53 PM, Eddy Nigg wrote:
> On 12/10/2012 09:44 PM, From Kathleen Wilson:
>>
>> Please do one more careful review of the proposed policy.
>>
>>
>
> I just noticed during a quick read:
>
> ..../a certificate that is *technically* capable of issuing
> certificates/ shows up a couple of times.
>
> I believe that the word /*technically*/ is not necessary. A CA
> certificates can't issue a certificate technically or non-technically.
> It may be technically constrained, but it can either issue or not.

I believe we can change all occurrences of

"technically capable of issuing certificates"

to
"capable of issuing certificates"
without changing the meaning of the proposed policy.

Then

"A certificate is deemed as technically capable of issuing certificates
if it contains an X.509v3 basicConstraints extension, with the cA
boolean set to true."

becomes

"A certificate is deemed as capable of issuing certificates if it

contains an X.509v3 basicConstraints extension, with the cA boolean set
to true."

Seems fine to me. Any objections?

>
> I personally wonder how you'd enforce that a certificate is either
> technically constrained *OR* publicly disclosed and audited. It seems to
> me not really enforceable, but that's probably something you already
> discussed. To me it looks like a red herring.
>

One way would be to have a white-list of publicly disclosed/audited
intermediate certs. But that assumes that the majority of intermediate
certs become technically constrained, which is what I hope will happen
as a result of the proposed policy.

Thanks,
Kathleen

[Eddy Nigg]

On 12/11/2012 12:08 AM, From Kathleen Wilson:

> Seems fine to me. Any objections?

Fine here too.

>
> One way would be to have a white-list of publicly disclosed/audited
> intermediate certs. But that assumes that the majority of intermediate
> certs become technically constrained, which is what I hope will happen
> as a result of the proposed policy.
>

Really? I'd expect the other thing, but who knows.... :-)

[Kathleen Wilson]

On 12/10/12 2:47 PM, Eddy Nigg wrote:
> On 12/11/2012 12:08 AM, From Kathleen Wilson:

>> I believe we can change all occurrences of
>> "technically capable of issuing certificates"
>> to
>> "capable of issuing certificates"
>> without changing the meaning of the proposed policy.
> >

>> Seems fine to me. Any objections?
>
> Fine here too.
>

Done.

"certificates that are capable of issuing certificates"
seems strange to me, but I can't think of a better (and precise) way to
phrase it.

>>
>> One way would be to have a white-list of publicly disclosed/audited
>> intermediate certs. But that assumes that the majority of intermediate
>> certs become technically constrained, which is what I hope will happen
>> as a result of the proposed policy.
>>
>
> Really? I'd expect the other thing, but who knows.... :-)
>

I think the cost of audits will give customers reason to consider the
technically-constrained option.

We'll see.

Thanks,
Kathleen

[Eddy Nigg]

On 12/11/2012 07:34 PM, From Kathleen Wilson:

> I think the cost of audits will give customers reason to consider the
> technically-constrained option.
>

Perhaps you meant the majority of the intermediate CA certs that are not
directly operated and used by the CA itself. There you might be right of
course.

[Erwann Abalea]

Le mardi 11 décembre 2012 18:34:25 UTC+1, Kathleen Wilson a écrit :
> "certificates that are capable of issuing certificates"
> seems strange to me, but I can't think of a better (and precise) way to
> phrase it.

"CA certificates used to verify certificates"?

[Rob Stradling]

On 08/12/12 00:45, Kathleen Wilson wrote:
> On 12/7/12 1:01 PM, Rob Stradling wrote:

> I updated the text again. Does that solve the problem?

Yes. Thanks.

[Rob Stradling]

On 08/12/12 00:48, Kathleen Wilson wrote:
> On 12/7/12 1:11 PM, Rob Stradling wrote:

Ah, I should have suggested "registered domain" rather than "registrable
domain".

> Updated the text to:
> "Each dNSName in permittedSubtrees must be a registrable domain (with
> zero or more subdomains) according to the Public Suffix List algorithm."
>
> Is the link that I used for "Public Suffix List algorithm" the correct one?

Yes.

> Does this new text need any further clarification?

Please change "registrable domain" to "registered domain". Thanks.

Clearly CAs should only issue certs to dNSNames (or containing
permittedSubtree dNSName constraints) where the domain name has been
validated. And a domain name obviously cannot be validated if it hasn't
even been registered yet!

[Rob Stradling]

On 11/12/12 18:14, Erwann Abalea wrote:
> Le mardi 11 décembre 2012 18:34:25 UTC+1, Kathleen Wilson a écrit :

>> "certificates that are capable of issuing certificates"
>> seems strange to me, but I can't think of a better (and precise) way to
>> phrase it.
>

> "CA certificates used to verify certificates"?

I agree with Erwann. CA Certificates don't issue certificates! We
should use the terminology correctly.

Issuance of a certificate (aka "Certification") is performed by a CA
(Certification Authority) using a Private Key.

Verification of a certificate is performed by anybody using a CA
Certificate that contains the corresponding Public Key.

[Eddy Nigg]

On 12/12/2012 11:01 AM, From Rob Stradling:

> I agree with Erwann. CA Certificates don't issue certificates! We
> should use the terminology correctly.

Well, I think that one issues certificates with a CA certificate. Except
in case you self-sign it.

> Issuance of a certificate (aka "Certification") is performed by a CA

> (Certification Authority) using a Private Key....

.....AND CA certificate.

> Verification of a certificate is performed by anybody using a CA
> Certificate that contains the corresponding Public Key.

This can be only done after the fact has been established of signing a
certificate. The action before you can verify if it chains to something
is what we are talking about, e.g. certificates that are capable of
issuing other certificates.

For example you can't issue with non-CA certificates other certificates
(well you can try, but the result would be disappointing).

[Rob Stradling]

On 12/12/12 09:37, Eddy Nigg wrote:
> On 12/12/2012 11:01 AM, From Rob Stradling:

>> I agree with Erwann. CA Certificates don't issue certificates! We
>> should use the terminology correctly.
>

> Well, I think that one issues certificates with a CA certificate.

Eddy,

Millions of users have copies of your Root CA Certificates. If it is
possible to issue a certificate using just a CA certificate (as you
appear to suggest), what - in your opinion - is preventing these users
from mis-issuing certs on your behalf?!?

> Except in case you self-sign it.
>

>> Issuance of a certificate (aka "Certification") is performed by a CA

>> (Certification Authority) using a Private Key....
>
> .....AND CA certificate.

Disagree. No CA Certificate is required in order to be able to issue.
All the CA needs is:
1. to know their Name
and
2. to use their Private Key

A CA Certificate is a convenient place from which to obtain their Name,
but that doesn't make it required for issuance.

>> Verification of a certificate is performed by anybody using a CA
>> Certificate that contains the corresponding Public Key.
>

> This can be only done after the fact has been established of signing a
> certificate. The action before you can verify if it chains to something

> is what we are talking about, e.g. certificates that are capable of
> issuing other certificates.

Eddy, I know that "certificates that are capable of issuing other
certificates" is what we have been talking about. But the point Erwann
and I are making is that this is not what we should be talking about,
because it doesn't make any sense!

In contrast, it does make sense to talk about "CA certificates used to
verify certificates". RFC5280 says (emphasis mine)...

"4.2.1.9. Basic Constraints
...
The cA boolean indicates whether the certified public key may be used
to VERIFY certificate signatures."

"4.2.1.3. Key Usage
...
The keyCertSign bit is asserted when the subject public key is
used for VERIFYING signatures on public key certificates."

Can you find any clause in RFC5280 that says that a CA Certificate
issues certificates?

> For example you can't issue with non-CA certificates other certificates
> (well you can try, but the result would be disappointing).

[Eddy Nigg]

On 12/12/2012 12:11 PM, From Rob Stradling:

> In contrast, it does make sense to talk about "CA certificates used to
> verify certificates".

Whatever you say, I don't really care - it's just nobody will really
understand it. By verifying a certificate I don't issue anything - so
lets verify certificates, I don't mind.

[Kathleen Wilson]

On 12/12/12 12:37 AM, Rob Stradling wrote:
>
> Please change "registrable domain" to "registered domain". Thanks.
>
> Clearly CAs should only issue certs to dNSNames (or containing
> permittedSubtree dNSName constraints) where the domain name has been
> validated. And a domain name obviously cannot be validated if it hasn't
> even been registered yet!
>

Done.

Thanks,
Kathleen

[Kathleen Wilson]

On 12/12/12 4:09 AM, Eddy Nigg wrote:
> On 12/12/2012 12:11 PM, From Rob Stradling:
>> In contrast, it does make sense to talk about "CA certificates used to
>> verify certificates".
>
> Whatever you say, I don't really care - it's just nobody will really
> understand it. By verifying a certificate I don't issue anything - so
> lets verify certificates, I don't mind.
>

"certificates that are capable of issuing certificates"
Seems correct to me, just seems strange.

"CA certificates used to verify certificates"

Doesn't seem precise enough for me. I think it leaves too much room for
interpretation.


maybe...

"certificates that are capable of issuing other certificates"

or

"certificates that are capable of signing certificates"

or

"certificates that are capable of signing other certificates"

Or we can just leave it as is.


Any strong preferences?


Thanks,
Kathleen

[Eddy Nigg]

On 12/12/2012 08:48 PM, From Kathleen Wilson:

> maybe...
>
> "certificates that are capable of issuing other certificates"
>
> or
>
> "certificates that are capable of signing certificates"
>
> or
>
> "certificates that are capable of signing other certificates"
>

or certificates that have the Certificate Signer Key Usage extension
enabled (to be precise).

[Peter Gutmann]

Kathleen Wilson <kwi...@mozilla.com> writes:

>"certificates that are capable of issuing certificates"
>Seems correct to me, just seems strange.

Why not just call the thing a CA certificate and be done with it? Some of the
PKIX RFCs go down the path that's been discussed here, using some incredibly
convoluted description where you have to stop and think every time you see it
used in order to determine that that what they're referring to is a standard
CA certificate. I would hope that anyone reading a PKI spec would know by now
what a CA is. Alternatively, if they don't know what a CA is then they
shouldn't be playing with the spec in the first place.

Peter.

[Peter Gutmann]

Kathleen Wilson <kwi...@mozilla.com> writes:

>Any strong preferences?

Since we're going down this path, could I propose:

A certificate with which, with all appropriate deference, one has a sincere
and sanguine expectation -- indeed confidence, indeed one might go so far as
to say hope -- that at the end of the day, when all relevant factors have
been taken into consideration, susceptible to being deemed to be such as to
merit a final verdict of having been by no means unsatisfactory in its
overall outcome and, in the final analysis, to give grounds for being
judged, on mature reflection, to have been conducive to generating a degree
of gratification which will be seen in retrospect to have been capable of
signing other certificates.

(Apologies to Sir Humphery Appleby).

Peter.

[Moudrick M. Dadashov]

On 12/13/2012 3:50 AM, Peter Gutmann wrote:
> Kathleen Wilson <kwi...@mozilla.com> writes:
>
>> "certificates that are capable of issuing certificates"
>> Seems correct to me, just seems strange.
> Why not just call the thing a CA certificate and be done with it? Some of the

Exactly, the X.509 way..

M.D.

> PKIX RFCs go down the path that's been discussed here, using some incredibly
> convoluted description where you have to stop and think every time you see it
> used in order to determine that that what they're referring to is a standard
> CA certificate. I would hope that anyone reading a PKI spec would know by now
> what a CA is. Alternatively, if they don't know what a CA is then they
> shouldn't be playing with the spec in the first place.
>
> Peter.
>

[Erwann Abalea]

Le jeudi 13 décembre 2012 02:50:14 UTC+1, Peter Gutmann a écrit :
> Why not just call the thing a CA certificate and be done with it? Some of the

I agree. Reading #9 with this wording is clear. It also has the benefit to not restrict CA certificates to "certificates used to issue certificates", and also logically applies to CRL-signing certificates or OCSP-signing certificates (in the sense of self-issued certificates).

> PKIX RFCs go down the path that's been discussed here, using some incredibly
> convoluted description where you have to stop and think every time you see it
> used in order to determine that that what they're referring to is a standard
> CA certificate. I would hope that anyone reading a PKI spec would know by now
> what a CA is. Alternatively, if they don't know what a CA is then they
> shouldn't be playing with the spec in the first place.

Considering the complexity of PKI as a whole, it's a high hope ;)

[Kathleen Wilson]

So #9 would be:
"All CA Certificates which directly or transitively chain to a

certificate included in Mozilla's CA Certificate Program, MUST be
operated in accordance with Mozilla's CA Certificate Policy and MUST
either be technically constrained or be publicly disclosed and audited.

- A certificate is deemed to be a CA Certificate if it contains an

X.509v3 basicConstraints extension, with the cA boolean set to true. The
term "subordinate CA" below refers to any organization or legal entity

that is in possession or control of a CA certificate.

- These requirements include all cross-certified certificates which
chain to a certificate that is included in Mozilla's CA Certificate
Program."

"CA Certificates" would link to rfc5280.

I think using "CA Certificate" would make it easier to read, but I'm
concerned that some readers may miss the point that it applies to all
intermediate certificates chaining up to their root.

Kathleen

[Erwann Abalea]

Le jeudi 13 décembre 2012 19:32:49 UTC+1, Kathleen Wilson a écrit :
> On 12/13/12 10:11 AM, Erwann Abalea wrote:

> > Le jeudi 13 d�cembre 2012 02:50:14 UTC+1, Peter Gutmann a �crit :

> >> Why not just call the thing a CA certificate and be done with it? Some of the
>
> > I agree. Reading #9 with this wording is clear. It also has the benefit to
> > not restrict CA certificates to "certificates used to issue certificates",
> > and also logically applies to CRL-signing certificates or OCSP-signing
> > certificates (in the sense of self-issued certificates).
> >
>
> >> PKIX RFCs go down the path that's been discussed here, using some incredibly
> >> convoluted description where you have to stop and think every time you see it
> >> used in order to determine that that what they're referring to is a standard
> >> CA certificate. I would hope that anyone reading a PKI spec would know by now
> >> what a CA is. Alternatively, if they don't know what a CA is then they
> >> shouldn't be playing with the spec in the first place.
> >
> > Considering the complexity of PKI as a whole, it's a high hope ;)
> >

> So #9 would be:
>
> "All CA Certificates which directly or transitively chain to a
> certificate included in Mozilla's CA Certificate Program, MUST be
> operated in accordance with Mozilla's CA Certificate Policy and MUST
> either be technically constrained or be publicly disclosed and audited.
>
> - A certificate is deemed to be a CA Certificate if it contains an
> X.509v3 basicConstraints extension, with the cA boolean set to true. The
> term "subordinate CA" below refers to any organization or legal entity
> that is in possession or control of a CA certificate.
> - These requirements include all cross-certified certificates which
> chain to a certificate that is included in Mozilla's CA Certificate
> Program."

That's how I read it.

We may again dispute on wether basicConstraints:CA should be true for a certificate not used to issue certificates (such as CRLsigning or OCSPsigning ones). I think this flag should be set, others may think the contrary.

> "CA Certificates" would link to rfc5280.
>
> I think using "CA Certificate" would make it easier to read, but I'm
> concerned that some readers may miss the point that it applies to all
> intermediate certificates chaining up to their root.

Peter said it well: "I would hope that anyone reading a PKI spec would know by now what a CA is. Alternatively, if they don't know what a CA is then they shouldn't be playing with the spec in the first place."

[Erwann Abalea]

Le jeudi 13 décembre 2012 19:32:49 UTC+1, Kathleen Wilson a écrit :

> On 12/13/12 10:11 AM, Erwann Abalea wrote:

> > Le jeudi 13 d�cembre 2012 02:50:14 UTC+1, Peter Gutmann a �crit :

> >> Why not just call the thing a CA certificate and be done with it? Some of the
>
> > I agree. Reading #9 with this wording is clear. It also has the benefit to
> > not restrict CA certificates to "certificates used to issue certificates",
> > and also logically applies to CRL-signing certificates or OCSP-signing
> > certificates (in the sense of self-issued certificates).
> >
>
> >> PKIX RFCs go down the path that's been discussed here, using some incredibly
> >> convoluted description where you have to stop and think every time you see it
> >> used in order to determine that that what they're referring to is a standard
> >> CA certificate. I would hope that anyone reading a PKI spec would know by now
> >> what a CA is. Alternatively, if they don't know what a CA is then they
> >> shouldn't be playing with the spec in the first place.
> >
> > Considering the complexity of PKI as a whole, it's a high hope ;)
> >

> So #9 would be:
>
> "All CA Certificates which directly or transitively chain to a
> certificate included in Mozilla's CA Certificate Program, MUST be
> operated in accordance with Mozilla's CA Certificate Policy and MUST
> either be technically constrained or be publicly disclosed and audited.
>
> - A certificate is deemed to be a CA Certificate if it contains an
> X.509v3 basicConstraints extension, with the cA boolean set to true. The
> term "subordinate CA" below refers to any organization or legal entity
> that is in possession or control of a CA certificate.
> - These requirements include all cross-certified certificates which
> chain to a certificate that is included in Mozilla's CA Certificate
> Program."

That's how I read it.

We may again dispute on wether basicConstraints:CA should be true for a certificate not used to issue certificates (such as CRLsigning or OCSPsigning ones). I think this flag should be set, others may think the contrary.

> "CA Certificates" would link to rfc5280.
>
> I think using "CA Certificate" would make it easier to read, but I'm
> concerned that some readers may miss the point that it applies to all
> intermediate certificates chaining up to their root.

Peter said it well: "I would hope that anyone reading a PKI spec would know by now what a CA is. Alternatively, if they don't know what a CA is then they shouldn't be playing with the spec in the first place."

[Rob Stradling]

On 13/12/12 18:45, Erwann Abalea wrote:
> Le jeudi 13 décembre 2012 19:32:49 UTC+1, Kathleen Wilson a écrit :

<snip>

>> "CA Certificates" would link to rfc5280.
>>
>> I think using "CA Certificate" would make it easier to read, but I'm
>> concerned that some readers may miss the point that it applies to all
>> intermediate certificates chaining up to their root.
>

> Peter said it well: "I would hope that anyone reading a PKI spec would know by now what a CA is. Alternatively, if they don't know what a CA is then they shouldn't be playing with the spec in the first place."

...and (if they don't know what a CA is) they probably shouldn't have
Root Certificate(s) in NSS either!


Kathleen, I think that linking to RFC5280 would be sufficient, because
RFC5280 Section 3.2 defines what a "CA Certificate" is...

This specification covers two classes of certificates: CA
certificates and end entity certificates. CA certificates may be
further divided into three classes: cross-certificates, self-issued
certificates, and self-signed certificates. Cross-certificates are
CA certificates in which the issuer and subject are different
entities. Cross-certificates describe a trust relationship between
the two CAs. Self-issued certificates are CA certificates in which
the issuer and subject are the same entity. Self-issued certificates
are generated to support changes in policy or operations. Self-
signed certificates are self-issued certificates where the digital
signature may be verified by the public key bound into the
certificate. Self-signed certificates are used to convey a public
key for use to begin certification paths. End entity certificates
are issued to subjects that are not authorized to issue certificates.

[Rob Stradling]

On 04/12/12 07:03, Stephen Schultze wrote:
> On 10/22/12 9:09 AM, Rob Stradling wrote:
<snip>
>> How about defining a simple XML (or JSON) schema?
>
> I am torn because that seems too complicated. I like the simplicity of
> the .tgz file.
>
> On the other hand, you could define an XML/JSON schema as you suggest --
> but do so quickly and require deployment in very short order.
>
> I do not like Kathleen's currently proposed text:

> "The Certificate Policy or Certification Practice Statement of the CA
> that has their certificate included in Mozilla's CA Certificate Program
> must specify where on that CA's website all such public disclosures are
> located."
>

> This is not sufficiently machine-readable to serve the original purpose
> for which the requirement was envisioned (ie: easy automated checking of
> all roots).
>
> Time to get this done.

On 30/11/12 20:11, Rob Stradling wrote:
> On 29/11/12 22:42, Kathleen Wilson wrote:
>> Any recommendations?
>
> I'll post a proposal soon.

Here's a first stab at a proposal. Comments welcome!

Step 1: Require every CA to provide Mozilla with a "Disclosure URL" for
each of their Root Certificates in NSS. These must be HTTPS URLs and
the contents at each URL must be JSON data. Each Root Certificate must
have a distinct Disclosure URL.

Step 2: Ask the NSS Team to define a new CKA_DISCLOSURE_JSON_URL
attribute type, and use this attribute type to add the Disclosure URL
for each Root Certificate to certdata.txt [1].

Step 3: At some point in the future, Mozilla could add code to
Firefox/NSS that will enforce the "technically-constrained or
publicly-disclosed-and-audited" policy. (IIRC, Brian has already stated
that this is Mozilla's long-term plan). I imagine that Mozilla would
regularly collect all of the latest disclosure data on the Mozilla
server-side, and then periodically push updates to each client using
existing mechanisms.
Other interested parties (e.g. EFF, ICSI, etc) could also write code
that will loop through the list of Roots in the NSS certdata.txt file,
automatically pick up the Disclosure URLs and download all of the
disclosure details.

JSON data requirements: This isn't a formal JSON schema definition, but
here's an example of what a JSON Disclosure file might look like...

{
"certificate_archive_url": "https://cert.acme.com/DisclosedCerts.p7c",
"subordinate_certificates": [
{
"description": "Acme Issuing CA 1",
"sha256_fingerprint":
"6d469f6a7b88ee5da4bf8ccdeeba718688589df105e191a45da2e432431b202f",
"cp_urls": [
"https://legal.acme.com/Acme_Certificate_Policy.pdf"
],
"cps_urls": [
"https://legal.acme.com/Acme_CPS_v1.pdf",
"https://legal.acme.com/Acme_CPS_EVAmendment2012.html"
],
"audits": [
"WebTrust": "https://cert.webtrust.org/ViewSeal?id=12345",
"WebTrust EV": "https://cert.webtrust.org/ViewSeal?id=12346"
]
},
{
"description": "Acme Partners CA 1",
"sha256_fingerprint":
"89930b6550fadbc0de50f9aef7c5bef2aebc96f9898f2b0db62982a988cce73f",
"cp_urls": [
"https://legal.acme.com/Acme_Certificate_Policy.pdf"
],
"cps_urls": [
"https://legal.acme.com/Acme_CPS_v1.pdf",
"https://legal.acme.com/Acme_CPS_EVAmendment2012.html"
],
"audits": [
"WebTrust": "https://cert.webtrust.org/ViewSeal?id=12345",
"WebTrust EV": "https://cert.webtrust.org/ViewSeal?id=12346"
],
"disclosure_url":
"https://cert.acme.com/AcmePartnersCA1_disclosure.json"
}
]
}

Notes:
certificate_archive_url - this is an HTTPS URL pointing to a P7C file
that contains all of the publicly disclosed Subordinate CA Certificates
issued by the relevant CA Certificate.
description - this should be the most descriptive attribute from the
Subordinate CA Certificate's Subject field (most likely the CN or OU field).
sha256_fingerprint - this is the SHA-256 digest of the DER-encoded
certificate. (The certificate itself must be present in the P7C file
pointed to by the certificate_archive_url).
cp_urls and cps_urls - these are arrays because the effective CP/CPS
may be spread across >1 document.
disclosure_url - this is a required field for each Subordinate CA
Certificate that does not have a Basic Constraints pathLenConstraint of
0. The URL points to another JSON disclosure file, which could be
hosted either by the Issuing CA or by the Subordinate CA. (If
pathLenConstraint=0, the disclosure_url field should be omitted).


[1]
https://mxr.mozilla.org/mozilla/source/security/nss/lib/ckfw/builtins/certdata.txt

[Peter Kurrasch]

Going back to your wording change, Kathleen--and trying to include the
comments made by others--here is my suggestion for how to update the
section:

On 12.13.2012 12:32 PM, Kathleen Wilson wrote:
> So #9 would be:
> "All CA Certificates which directly or transitively chain to a
> certificate included in Mozilla's CA Certificate Program, MUST be
> operated in accordance with Mozilla's CA Certificate Policy and MUST
> either be technically constrained or be publicly disclosed and audited.
> - A certificate is deemed to be a CA Certificate if it contains an
> X.509v3 basicConstraints extension, with the cA boolean set to true.
> The term "subordinate CA" below refers to any organization or legal
> entity that is in possession or control of a CA certificate.
> - These requirements include all cross-certified certificates which

> chain to a certificate that is included in Mozilla's CA Certificate
> Program."
- Informally, the term "CA Certificates" refers to both root and
intermediate certificates. A formal definition is provided by
<hotlink>RFC 5280, section 3.2.


I agree with the others that people will probably understand what is
meant by CA Certs. At the same time I think it's okay to include
language that gives people a warm fuzzy--it's a "okay, yeah, I
understand this section" type of thing.

Please feel free to tweak that wording, of course.

[Kathleen Wilson]

Thank you all for your thoughts and suggestions about this.

I'm still worried that people who read it quickly will simply interpret
it as "All CA Certificates MUST be operated in accordance with
Mozilla's CA Certificate Policy." Then they'll think, "well, of course",
and not read the rest of the requirement and not realize that it is
referring to all intermediate certificates.

I changed

"certificates that are capable of issuing certificates"

to
"certificates that are capable of being used to issue new certificates"

So now the text is:
"9. All certificates that are capable of being used to issue new
certificates, and which directly or transitively chain to a certificate

included in Mozilla's CA Certificate Program, MUST be operated in
accordance with Mozilla's CA Certificate Policy and MUST either be
technically constrained or be publicly disclosed and audited.

- A certificate is deemed as capable of being used to issue new
certificates if it contains an X.509v3 basicConstraints extension, with

the cA boolean set to true. The term "subordinate CA" below refers to
any organization or legal entity that is in possession or control of a

certificate that is capable of being used to issue new certificates.

- These requirements include all cross-certified certificates which
chain to a certificate that is included in Mozilla's CA Certificate
Program."

While it's not as nice as the suggestions that have been discussed, it
is technically accurate and will hopefully catch the reader's attention,
causing them to realize that this requirement is for all intermediate
certificates.

http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html
(Items #9 and #11 updated. Diff of changes can be viewed by scrolling to
bottom of page and clicking on "Last modified on...")

Thanks,
Kathleen

[Rob Stradling]

On 18/12/12 18:24, Kathleen Wilson wrote:
<snip>

> I changed

> "certificates that are capable of issuing certificates"

> to
> "certificates that are capable of being used to issue new certificates"

Kathleen, I still disagree. Certificates never issue certificates.

Certificates are issued by CAs, who have knowledge of their Name and
access to their Private Key.

CA Certificates are used to _verify_ that a certificate was indeed
issued by the CA.

<snip>

> - A certificate is deemed as capable of being used to issue new

> certificates if it contains an X.509v3 basicConstraints extension, with

> the cA boolean set to true.

Hmmm, this places X.509 v1 and v2 certificates out of scope. Does NSS
allow X.509 v1/v2 certificates to be used as intermediate certificates?

"GTE Cybertrust Global Root" is an X.509 v1 certificate that is trusted
by NSS, and there may be others. The current item #9 text seems to
imply that the GTE Root doesn't have to "be operated in accordance with
Mozilla's CA Certificate Policy", because the MUST only applies to X.509
v3 certs.

[Ryan Sleevi]

On Wed, December 19, 2012 2:23 am, Rob Stradling wrote:
> On 18/12/12 18:24, Kathleen Wilson wrote:
> <snip>
> > I changed

> > "certificates that are capable of issuing certificates"

> > to
> > "certificates that are capable of being used to issue new certificates"
>
> Kathleen, I still disagree. Certificates never issue certificates.
>
> Certificates are issued by CAs, who have knowledge of their Name and
> access to their Private Key.
>
> CA Certificates are used to _verify_ that a certificate was indeed
> issued by the CA.
>
> <snip>
> > - A certificate is deemed as capable of being used to issue new

> > certificates if it contains an X.509v3 basicConstraints extension, with

> > the cA boolean set to true.
>

> Hmmm, this places X.509 v1 and v2 certificates out of scope. Does NSS
> allow X.509 v1/v2 certificates to be used as intermediate certificates?

The proposed policy requires the Baseline Requirements, which does
expressly prohibits X.509v1 and X.509v2 certificates (for root and
intermediate). See Appendix B of BR 1.0.

Of course, Appendix B concerns itself with the issuance of NEW
certificates. So any existing v1/v2 intermediates would not meet the
definition, and could just as well be argued that they aren't in scope for
BR audits. Which, I think, is pretty far from the intent of Mozilla's
policy.

Under such a scheme, it means the ONLY option for CAs which have issued
such certificates is revoke or disclose. I leave it to Mozilla to comment
on how they see the revocation process for such certificates working,
given the current revocation handling in Mozilla products.

Certainly, it seems like "something" needs to be clarified with regards
with how existing certs are grandfathered in - both intermediate and
subscribers - that do not conform to the requirements of the BR. The
policy text seems to assume that all certs going forward are BR-compliant.

Notably, the original language (that was objected to) lacked this loop
hole, because it deemed all certificates lacking the explicit X.509v3
basicConstraints extension with CA false as being "technically capable".
This meant it included all v1 and v2 certs, by definition.

There are ways to incorporate the "v1/v2 OR v3 with
basicConstraints:CA=TRUE" into the language, but I think you've raised a
broader point, which is "How will Mozilla handle existing certs", since
there will be no v1/v2 certs going forward.

>
> "GTE Cybertrust Global Root" is an X.509 v1 certificate that is trusted
> by NSS, and there may be others. The current item #9 text seems to
> imply that the GTE Root doesn't have to "be operated in accordance with
> Mozilla's CA Certificate Policy", because the MUST only applies to X.509
> v3 certs.
>
> --
> Rob Stradling
> Senior Research & Development Scientist
> COMODO - Creating Trust Online
>

[Kathleen Wilson]

According to
https://wiki.mozilla.org/CA:CertPolicyUpdates#Transitioning_to_the_Updated_Policy_Version_2.1
"Items #9, 10, and 11: Regarding subordinate CAs:
- All subordinate CA certificates that are issued after May 1, 2013 must
comply with version 2.1 of the Inclusion Policy
- All pre-existing subordinate CA certificates must be updated to comply
with version 2.1 of the Inclusion Policy for new certificate issuance by
May 1, 2014.
- All certificates that are capable of being used to issue new
certificates must comply with version 2.1 of the Inclusion Policy for
new certificate issuance by May 1, 2014. "

I interpret this to mean that if an existing intermediate certificate
does not meet the policy, then it will have to be revoked and replaced
with a certificate that does meet the policy, or it will have to be
audited/disclosed.

>>
>> "GTE Cybertrust Global Root" is an X.509 v1 certificate that is trusted
>> by NSS, and there may be others. The current item #9 text seems to
>> imply that the GTE Root doesn't have to "be operated in accordance with
>> Mozilla's CA Certificate Policy", because the MUST only applies to X.509
>> v3 certs.
>>
>>

I looked through all the certs in NSS, and found that the following
certs are version 1.

Owner: Verizon
CN = GTE CyberTrust Global Root

Owner: SECOM
CN = http://www.valicert.com/
OU = ValiCert Class 1 Policy Validation Authority

Owner: GoDaddy
CN = http://www.valicert.com/
OU = ValiCert Class 2 Policy Validation Authority

Owner: RSA
CN = http://www.valicert.com/
OU = ValiCert Class 3 Policy Validation Authority

Owner : Symantec (VeriSign)
- Class 1 Public Primary Certification Authority
- Class 1 Public Primary Certification Authority - G2
- VeriSign Class 1 Public Primary Certification Authority - G3
- Class 2 Public Primary Certification Authority - G2
- VeriSign Class 2 Public Primary Certification Authority - G3
- Class 3 Public Primary Certification Authority (MD2)
- Class 3 Public Primary Certification Authority (SHA-1)
- Class 3 Public Primary Certification Authority - G2
- VeriSign Class 3 Public Primary Certification Authority - G3
- VeriSign Class 4 Public Primary Certification Authority - G3

I asked Symantec about their VeriSign cert issuance and they replied:
“All intermediates and end-entity certs are v3.”

Do we need to add text to item #9 in
http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html
to specifically say that v1/v2 intermediate certs are not allowed?

e.g.

"Certificates which directly or transitively chain to a certificate

included in Mozilla's CA Certificate Program, MUST be of type X.509 v3."


Kathleen

[Ryan Sleevi]

On Thu, December 20, 2012 10:13 am, Kathleen Wilson wrote:
> On 12/19/12 11:53 AM, Ryan Sleevi wrote:

> According to
> https://wiki.mozilla.org/CA:CertPolicyUpdates#Transitioning_to_the_Updated_Policy_Version_2.1
> "Items #9, 10, and 11: Regarding subordinate CAs:
> - All subordinate CA certificates that are issued after May 1, 2013 must
> comply with version 2.1 of the Inclusion Policy
> - All pre-existing subordinate CA certificates must be updated to comply
> with version 2.1 of the Inclusion Policy for new certificate issuance by
> May 1, 2014.
> - All certificates that are capable of being used to issue new
> certificates must comply with version 2.1 of the Inclusion Policy for
> new certificate issuance by May 1, 2014. "
>
> I interpret this to mean that if an existing intermediate certificate
> does not meet the policy, then it will have to be revoked and replaced
> with a certificate that does meet the policy, or it will have to be
> audited/disclosed.
>
>
> >>

> >> "GTE Cybertrust Global Root" is an X.509 v1 certificate that is
> >> trusted
> >> by NSS, and there may be others. The current item #9 text seems to
> >> imply that the GTE Root doesn't have to "be operated in accordance
> >> with
> >> Mozilla's CA Certificate Policy", because the MUST only applies to
> >> X.509
> >> v3 certs.
> >>
> >>
>

The Baseline Requirements already specify that, so it's a question of how
you read the requirements of Item 13.

"CA operations and issuance of certificates to be used for SSL-enabled
servers" can be read either as:

"(CA operations and issuance of certificates) to be used for SSL-enabled
servers"
or
"(CA operations) and (issuance of certificates to be used for
SSL-enabled servers)"

The difference between the two interpretations is this: The former permits
a reading that suggests that a CA root can issue intermediates outside of
the terms of the Baseline Requirements, under the argument that they're
not to be used for SSL. The latter "should" close this loophole, but
someone motivated might try to argue that sections like Appendix B of the
BR do not count as "CA operations" requirements, ergo the profile of an
Intermediate certificate (including the MUST be v3) do not count as "CA
operations". That's a tenuous argument, but when has that ever stopped
anyone?

Quite simply, I believe Mozilla should make it explicitly clear (perhaps
in Section 6) that the requirements of Mozilla's policy - and of the
Baseline Requirements - apply to the entire certificate hierarchy. That
is, any certificate that is signed by a CAs root key (and name), or any
certificate that transitively terminates in a certificate that is signed
by the CAs root key (and name) MUST conform with both.

This covers cross-signed certs, "internal use only" certs, ANY cert that
might successfully validate to the included trust anchor. Anything short
of that, and you run the risk of security incident, because you've allowed
a place for the issuance of certificates to proceed unaudited /
unverified.

The only "troublesome" part of the BRs, as they relate to issuance of
certificates for other purposes, is likely Section 9.2.1 (the requirement
of the subjectAltName) and 9.2.2 (Subject Common Name). That is, I think,
the only hole that should be carved, and only when issuing certificates
that DO NOT contain a DNS/IP address (eg: S/MIME, Code signing, etc)

>
> e.g.

> "Certificates which directly or transitively chain to a certificate

> included in Mozilla's CA Certificate Program, MUST be of type X.509 v3."
>
>
> Kathleen
>
>
>
>
>
>
>

[Kathleen Wilson]

On 12/20/12 12:29 PM, Ryan Sleevi wrote:
> On Thu, December 20, 2012 10:13 am, Kathleen Wilson wrote:
>> On 12/19/12 11:53 AM, Ryan Sleevi wrote:
>>> On Wed, December 19, 2012 2:23 am, Rob Stradling wrote:
>>>> <snip>
>>>>> - A certificate is deemed as capable of being used to issue new
>>>>> certificates if it contains an X.509v3 basicConstraints extension,
>>>>> with
>>>>> the cA boolean set to true.
>>>>
>>>> Hmmm, this places X.509 v1 and v2 certificates out of scope. Does
>>>> NSS
>>>> allow X.509 v1/v2 certificates to be used as intermediate
>>>> certificates?

>>> <snip>

> Quite simply, I believe Mozilla should make it explicitly clear (perhaps
> in Section 6) that the requirements of Mozilla's policy - and of the
> Baseline Requirements - apply to the entire certificate hierarchy. That
> is, any certificate that is signed by a CAs root key (and name), or any
> certificate that transitively terminates in a certificate that is signed
> by the CAs root key (and name) MUST conform with both.
>

In the BR document version 1.1, Section 1 about Scope says:
"This version of the Requirements only addresses Certificates intended
to be used for authenticating servers
accessible through the Internet. Similar requirements for code signing,
S/MIME, time-stamping, VoIP, IM, Web
services, etc. may be covered in future versions."

However, Mozilla's CA Certificate Policy must also address S/MIME and
code signing certificates.

So I think we have to address the v1/v2 cert issue in some way.
Is there a better way to do this than adding the following?