[cabfpub] Name Constraints, Auditing and EKU

[Steve Roylance]

Thanks Rob.  

A great in-depth review.    I've simplified the text and amended
appropriately in the attachment.  I've also corrected the PDF busing
Office on Windows 7 where as my Office 2011 for Mac decided to delete the
references in section 17.4.  Consistency between platforms, now there's an
interesting subject ;-)

Steve



On 22/04/2013 11:12, "Rob Stradling" <rob.stradling at comodo.com> wrote:

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

I reconsidered this section and decided to remove all elements as there
was too much repetition but in reverse from section 9.1 (i.e. Issuer vs
Subject) leaving only a clarification that the SubCA Subject should ensure
the requirements of section 9.1 (Issuer) could be met.

9.3 Subject Information ­ Subordinate
CA CertificatesBy issuing a Subordinate CA Certificate, the CA represents
that it followed the procedure set forth in its Certificate Policy and/or
Certification Practice Statement to verify that, as of the Certificate¹s
issuance date, all of the Subject Information was accurate in allowing a
SubCA to create certificates that have an Issuer which meets the
requirements of section 9.1


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

I'll scrub this item.   It was an attempt to say, don't create a CA that
expires on a date later than the expiry date of the CA you used to create
it..but as you say it's a moving target.

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

Best practice?  Root 20 years, Issuing CA 10 years end entity up to 5
years, but again a moving target.

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

I agree that it's better to push the requirements of Name Constraints here
than the previous "Note:- If NameConstraints are used within.. " from
section 9.3.2 onwards.

Thanks for plugging the hole - (Side note - Do we need to also amend the
language in the Mozilla Policy accordingly.)

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

The BRs allow for Client Authentication Certificates as Appendix B (3) F
states that end entities might not have Server Authentication so it
follows that the issuing CA would not need one either:-

F. extKeyUsage (required)
Either the value id-kp-serverAuth [RFC5280] or id-kp-clientAuth [RFC5280]
or both values MUST be present.  id-kp-emailProtection [RFC5280] MAY be
present.  Other values SHOULD NOT be present.

I prefer to keep so that as we try to expand the BRs to encompass best
practice for more types the meaning is not lost.

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

I don't wish to complicate my proposal with that discussion so I'll
simplify it to:-
(a) For each dNSName in permittedSubtrees, the CA MUST confirm that the
Applicant has registered the
dNSName or has been authorized by the domain registrant to act on the
registrant's behalf in line with the verification practices of section 11.1


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

Agreed. Amended.

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

Agreed. Amended

>
>
>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)?!?
>

Agreed. Amended, so should Mozilla's policy wording be amended too?

>
>10. Section 17.4:
>There are 3 references to Section 0.  Where's that?

Odd.  But solved using Microsoft on Microsoft.

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

As per my above point we'd have to look at the wording of B(3)F first.

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

I'll let Ryan Hurst make some comments here, but initial testing without
id-kp-OCSPSigning suggest that MSCA based implementations do not work
unless the EKU is included.   Exclusion of all EKUs (As an option to
inclusion of specific uses) seems to be equivalent to allowing all in
various non browser platforms.

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

It would be superb if all platforms supported all functions in the same
way and with the same intent and with 100% ubiquity.  Reality is that they
don't.  Extensive testing with customers has so far resulted in the need
for a mix and match approach for EKU and NC.  Not ideal but stronger than
no constraints.

Sentence amended to:-

"** Extended Key Usage within Subordinate CAs is an exception to RFC 5280
that MAY be used to
further protect relying parties until the use of the extension is
consistent
between Application Software Suppliers whose software is used by a
substantial
portion of Relying Parties worldwide."


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: BRv.1.1.4 - Amendments for Name Constraints and Auditing -	Updated 22nd April.pdf
Type: application/pdf
Size: 356780 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20130423/72b5baae/attachment-0003.pdf>