[cabfpub] Name constrained certificate examples

[Erwann Abalea]

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 <http://www.globalsign.co.uk/> | 
> www.globalsign.eu <http://www.globalsign.eu/>
>
> Description: Description: secured-by-globalsign.gif
>
> **
>
> Springfield House, Sandling Road, Maidstone, Kent, ME14 2LP, UK.
>
> Tel: +44 1622 766766  Fax: +44 1622 662255
>
> Description: Description: oneclick-2
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20130717/f2c7556e/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 3627 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20130717/f2c7556e/attachment-0004.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 25835 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20130717/f2c7556e/attachment-0005.gif>