[cabfpub] Ballot 105 Technical Constraints for Subordinate Certificate Authorities yielding broader and safer PKI adoption.

[Erwann Abalea]

Bonjour,

Late reply (due to vacation), inline.

-- 
Erwann ABALEA

Le 13/07/2013 02:32, Rick Andrews a écrit :
> Section 9.7: A question about DirName in your example:
>
> X509v3 Name Constraints:
>
> Permitted:
>
> DNS:example.com
>
> DirName: C=US, ST=MA, L=Boston, O=Example LLC
>
> If a Subordinate CA contains this in its Name Constraints extension, 
> does that mean that compliant browsers will reject any end entity 
> certificate issued by this Subordinate CA unless the DN of the end 
> entity cert is "C=US, ST=MA, L=Boston, O=Example LLC, CN=<zero or more 
> labels>.example.com"?
>

My reading of the standard about NameConstraints lead me to think that:

  * a certificate containing an empty subject name and a SAN/dnsName
    with "<anything>.example.com" will be valid. No security problem.
  * a certificate containing a subject name "C=US, ST=MA, L=Boston,
    O=Example LLC, CN=*.google.com" (without any SAN/dnsName or with a
    SAN/dnsName="<anything>.example.com" will be valid. Potential
    security problem if the CA doesn't follow CABF BR rules (i.e. always
    have SAN extension, always copy the CN into SAN/{dnsName, ipAddress}
    if it contains a FQDN or an IP address).
  * a certificate containing a subject name "C=US, ST=MA, L=Boston,
    O=Example LLC, O=Google, CN=*.google.com" (with same remarks as
    above regarding SAN) will be valid. Same security risks, and the
    browser may display the wrong Organization in dedicated UI elements.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20130717/d6b97146/attachment.html