[cabfpub] Ballot 105 Technical Constraints for Subordinate Certificate Authorities yielding broader and safer PKI adoption.
Erwann Abalea
erwann.abalea at keynectis.com
Wed Jul 17 12:46:53 UTC 2013
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: <http://lists.cabforum.org/pipermail/public/attachments/20130717/d6b97146/attachment-0003.html>
More information about the Public
mailing list