[cabfpub] Name Constraints, Auditing and EKU
rob.stradling at comodo.com
Mon Apr 22 03:12:28 MST 2013
On 27/03/13 13:49, Steve Roylance wrote:
> I'm looking for a couple of volunteers to whip this into shape. Any takers?
Hi Steve. As requested, here are some comments on your proposal...
1. Section 9.3.2a:
"Note:- If NameConstraints are used within the Subordinate CA this
field MUST be duplicated into at least one
You need to explicitly state that the "at least one" entry needs to go
into permittedSubtrees rather than excludedSubtrees! (This comment
applies to various other paragraphs in section 9.3.* as well).
2. Section 9.5.2:
"Subordinate CA Certificates issued after the Effective Date MUST
not exceed the Validity Period of the Certificate from which they
This doesn't make sense to me. Certificates are issued by CAs, not by
Certificates. Each CA can be the Subject of an unlimited number of CA
Certificates, each cert potentially having a different Validity Period.
Furthermore, some of the CA Certificates might be issued more recently
than some of the Certificates that the CA has issued!
(Steve, I know you know this already, because GlobalSign have issued 2
certificates with different expiry dates for the "GlobalSign Root CA" ;-) ).
3. Section 9.5.2:
"and by a rule of thumb should not exceed 50% of duration of the
Certificate from which they were issued"
4. Section 9.8:
I just spotted a gaping hole in the language. As written, the Name
Constraints extension could include dNSName=foo.com in excludedSubtrees
and this would be regarded as "technically constrained", even though it
wouldn't prevent certs being issued to bar.com, google.com, etc!
One way to fix this would be to extend the final paragraph of this
section to something like...
"If the subordinate CA is not allowed to issue certificates with
dNSNames, then the subordinate CA certificate MUST include a
zero-length dNSName in excludedSubtrees. Otherwise, the
subordinate CA certificate MUST include at least one
dNSName in permittedSubtrees."
A similar "MUST include at least one...in permittedSubtrees" fix is
required for iPAddress too.
5. Section 9.8:
"If the Subordinate CA certificate includes the id-kp-serverAuth
extended key usage..."
When wouldn't this be the case? The scope of the BRs is still...
"This version of the Requirements only addresses Certificates
intended to be used for authenticating servers accessible through
6. Section 9.8(a):
"...according to the Public Suffix List algorithm."
I think this language should be redrafted so that it is consistent with
Section 11.1.3. (i.e. the PSL is current best practice but it might be
superseded by an RFC at some point, etc, etc).
(Maybe there needs to be a new section in the BRs that just deals with
determining what is a registered/registrable domain, which other
sections can then refer to).
7. Section 11.1.1:
"FQDNs may be listed in...Subordinate CA certificate via dNSNames
in Name Constraints"
That statement is true, but IMHO it's misleading. A dNSName constraint
for foo.com affects foo.com, www.foo.com and
unlimited.levels.of.subdomain.foo.com. By definition, you don't add
sub-domains to an "FQ"DN.
Also, I presume you're talking about dNSNames in permittedSubtrees
(rather than excludedSubtrees), but I think you should so say explicitly.
8. Section 11.1.2:
"IPAddresses may be listed...in Subordinate CA certificate via
IPAddress in Name Constraints"
Again, state explicitly that you mean permittedSubtrees.
9. Section 17:
"...or unconstrained and audited in line with all requirements from
I don't understand the "unconstrained" requirement. Why should a CA
that is audited by WebTrust/ETSI be _banned_ from having Name
Constraints in their CA Certificate(s)?!?
10. Section 17.4:
There are 3 references to Section 0. Where's that?
11. Appendix B(2)G:
"For Subordinate CA Certificates with Name Constraints then either
the value id-kp-serverAuth [RFC5280] or id-kp-clientAuth [RFC5280]"
Given the scope of the BRs (see my comment 5 above), when would
id-kp-serverAuth ever be omittable?
12. Appendix B(2)G:
"id-kp-OCSPSigning MUST be present"
Disagree. The OCSP Signing trust purpose is not supposed to be passed
down from the Root, and AFAIK there is no way to prevent a Subordinate
CA from issuing delegated OCSP Signing Certificates! (If you have
evidence to the contrary, please say).
13. Appendix B(2)G:
"** Extended Key Usage within Subordinate CAs is an exception to
RFC 5280 that MAY be used to further protect relying parties until
the Name Constraints extension is supported by Application
Software Suppliers whose software is used by a substantial portion
of Relying Parties worldwide."
I agree that we should note that this is "an exception to RFC 5280".
However, I don't think Mozilla have any plans to stop requiring EKU once
Name Constraints are supported more widely, since EKU and Name
Constraints achieve different things.
Senior Research & Development Scientist
COMODO - Creating Trust Online
More information about the Public