[cabfpub] Name constrained certificate examples

Ryan Sleevi sleevi at google.com
Wed Jul 17 19:54:26 UTC 2013


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 ****
>
> ** **
>
> [image: Description: Description: secured-by-globalsign.gif]****
>
> * *
>
> Springfield House, Sandling Road, Maidstone, Kent, ME14 2LP, UK. ****
>
> Tel: +44 1622 766766  Fax: +44 1622 662255****
>
> [image: Description: Description: oneclick-2]****
>
> ** **
>
> ** **
>
>
>
> _______________________________________________
> 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/3efe3f01/attachment-0003.html>


More information about the Public mailing list