[cabfpub] Name constrained certificate examples

Wed Jul 17 22:30:45 UTC 2013

Hi Erwann. 

Are you happy that Name Constraints are good and the ballot is fine as worded?

Sent from my iPhone

On 17 Jul 2013, at 20:54, Ryan Sleevi <sleevi at google.com> wrote:

> http://bugzil.la/394919 describes the behaviour of NSS (both legacy and libpkix) with respect to nameConstraints.
> 
> In all cases, the Subject name MUST be compliance with the NC.PermittedSubTrees.directoryName if present.
> IF no SAN is present (meaning the CN will be treated as a host name, as described in RFC 6125), then the CN MUST ALSO be compliant with the NC.PermittedSubTrees.dnsNames.
> 
> This is not required by RFC 5280.
> 
> I'm not sure I understand your question re: IDN comparisons. The dnsNames subtree is an IA5String, so it must be punycoded (per 7.2 of 5280).
> 
> NSS expects the hostname-to-be-validated as ASCII (eg: Punycoded) and performs an ASCII-code-point equivalence test when comparing the CN to the hostname. As such, if the CN contains a non-punycoded name,  no subjectAltName is present (eg: in violation of the BRs), but the dNSNames contains a punycoded subtree, then the certificate will be rejected (non-ASCII equivalence). eg: It does not punycode the CN before comparison.
> 
> CryptoAPI is different, in that before performing hostname equivalence checks as part of the SSL policy, the common name will be punycoded/normalized. ISTR this goes as far back as roughly the IE 3.0/5.0 implementation of CAPI (it's been a long while since I've tested this aspect).
> 
> It can be argued that such policies are particular aspects of SSL hostname validation, and thus more reflected in RFC 6125 than RFC 5280. OpenSSL's lack of an RFC 2818/6125 hostname validation routine (which has caused an unending set of bugs in language bindings) can similarly be blamed for why such certificates are accepted.
> 
> The only use of heuristics that I'm aware of are with respect to whether the CN looks like an IP address.
> - OS X (which doesn't do NCs...) uses a heuristic to see if the CN parses as an IPv4 address when matching host address (does not support IPv6...).
> - CryptoAPI does no such parsing, IIRC, and thus I believe does not constrain the CN to permittedSubTrees.iPAddress
> - NSS always treats the CN as a dNSName, and thus does not check that whether permittedSubtrees.iPAddress overlaps. I've filed http://bugzil.la/895063 for this.
> 
> 
> 
> On Wed, Jul 17, 2013 at 10:52 AM, Erwann Abalea <erwann.abalea at keynectis.com> wrote:
>> Bonjour,
>> 
>> Reading the X.509 standard (8.4.2.2 and Annex G):
>> SSL1.cer is invalid because it has a SAN/dnsName containing "anything.example.com" and its issuer CA has a NameConstraints only allows dnsNames ending in "onlythis.com"; could you produce certificates with matching names ("google.com"/"onlythis.com")?
>> SSL2.cer is invalid for the same reason.
>> SSL3.cer is valid ("C=US, ST=MA, L=Boston, O=Example LLC, O=Google, CN=*.google.com" is a subordinate of "C=US, ST=MA, L=Boston, O=Example LLC", which is the only permitted directoryName form, and the EE cert doesn't contain a SAN extension).
>> I tried to find equivalent tests in PKITS, with no luck (the closer I get is with a NC permitting a DN and an rfc822Name, and the EE has its email in the SAN, not in the subject).
>> 
>> 
>> Testing with real browsers gives:
>> FF22.0, SSL1.cer, SSL2.cer, SSL3.cer: NOK
>> L'autorité de certification pour ce certificat n'est pas autorisé à délivrer un certificat avec ce nom.
>> (Code d'erreur : sec_error_cert_not_in_name_space)
>> IE8/XPSP3, SSL1.cer, SSL2.cer, SSL3.cer: NOK
>> Le certificat de sécurité présenté par ce site Web a été émis pour une autre adresse de site Web.
>> I guess that Chrome and Safari will produce the same result on that platform.
>> Opera12.15/XPSP3, SSL1.cer, SSL2.cer: NOK
>> Connexion sécurisée: erreur fatale (47)
>> Opera12.15/XPSP3, SSL3.cer: OK (owner is shown as           "*.google.com, Example LLC, Google")
>> OpenSSL-based clients, SSL1.cer, SSL2.cer: NOK
>> Verify return code: 47 (permitted subtree violation)
>> OpenSSL-based clients, SSL3.cer: OK
>> 
>> It seems FF and CAPI (XPSP3) consider that the CN is to be       validated as a dnsName and not part of the directoryName (whence, it's validated against NC.PermittedSubTrees.dnsName instead of NC.PermittedSubTrees.directoryName). This behaviour isn't       mentioned in RFC5280 either, but it's logical (legacy use of email addresses in the subjectName is also mentioned in RFC5280, and the same kind of treatment regarding NC extension is proposed). However, I don't know if that behaviour is the result of heuristics (does the CN look like a FQDN?), and how all this will work with internationalized domain names. There's room for failures.
>> 
>> Opera uses OpenSSL, clearly, and they both follow X.509 to the letter.
>> 
>> I don't have anything more recent than XPSP3 as a VM, sorry.
>> 
>> -- 
>> Erwann ABALEA
>> 
>> Le 17/07/2013 17:09, Ben Lightowler a écrit :
>>> Hi Erwann,
>>> 
>>>  
>>> 
>>> Steve asked me to put together some example certificates based on your concerns surrounding Name Constraints please find a zip attached with a Root and Issuing CA, as well as three SSL certificate created to your specifications in the examples you gave earlier.
>>> 
>>>  
>>> 
>>> Hope this helps,
>>> 
>>>  
>>> 
>>> Ben Lightowler
>>> 
>>> Sales Engineer
>>> 
>>>  
>>> 
>>> GlobalSign
>>> 
>>> +44  (0) 1622 766766
>>> 
>>> www.globalsign.co.uk | www.globalsign.eu
>>> 
>>>  
>>> 
>>> 
>>> 
>>>  
>>> 
>>> Springfield House, Sandling Road, Maidstone, Kent, ME14 2LP, UK.
>>> 
>>> Tel: +44 1622 766766  Fax: +44 1622 662255
>>> 
>>> 
>>> 
>>>  
>>> 
>>>  
>>> 
>> 
>> 
>> _______________________________________________
>> Public mailing list
>> Public at cabforum.org
>> https://cabforum.org/mailman/listinfo/public
> 
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20130717/4b1d429d/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4041 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20130717/4b1d429d/attachment-0001.p7s>