[cabfpub] Name Constraints, Auditing and EKU

[Rob Stradling]

On 27/03/13 13:49, Steve Roylance wrote:
<snip>
> 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
      nameConstraints:directoryName:orgaizationName"

s/orgaizationName/organizationName

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
      were issued"

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"

Why?


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


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"

s/certificate/Certificates

Again, state explicitly that you mean permittedSubtrees.


9. Section 17:
     "...or unconstrained and audited in line with all requirements from 
section 17."

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.


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