Re: [certid] It is not always a good idea to enforce CN check as leaf RDN only

[Bruno Harbulot <[e-mail]>]

On 18/03/2010 03:59, Peter Saint-Andre wrote:
> On 3/17/10 7:43 AM, ArkanoiD wrote:
>
>> Many self-signed certificates seem to have an email address as leaf
>> RDN.
>
> This I-D does not cover self-signed certs, only CA-issued certs.

I'm not sure this I-D should treat self-signed certs completely 
differently from CA-issued certs. Self-signed certs could be considered 
as a special case of CA-issued certs.
I think the logic of verifying the identity of the server ought to be 
separate from the logic of verifying trust in a certificate (although 
the latter could impose constraints on the former depending on policies).


This problem isn't just for self-signed certificate.

For you information, the UK e-Science CA [1] emits certificates for 
hosts with an e-mail address as leaf RDN, for example ('openssl x509' 
notation -> leaf is right-most):

C=UK, O=eScience, OU=Authority, L=CLRC, CN=ca.grid-support.ac.uk, 
emailAddress=[e-mail]

All the host certificates I've seen for this CA have an e-mail address 
as leaf.


Independently, I recently got a certificate like this, issued by the 
JANET CA [2] (compatible with most browsers out of the box):

- Subject: CN=foafssl.vidar.ngs.manchester.ac.uk, C=GB, L=Manchester, 
O=The University of Manchester, OU=Research Computing Services, 
CN=foafssl.ngs.manchester.ac.uk
- X509v3 Subject Alternative Name:
     DNS:foafssl.ngs.manchester.ac.uk,
     DNS:foafssl.vidar.ngs.manchester.ac.uk

While I must admit I was surprised to see a CN either side, it doesn't 
really matter; it's still fine with the RFC 2818 rule and the fact that 
the host name is also in the Subject DN's CNs is irrelevant:

>    If a subjectAltName extension of type dNSName is present, that MUST
>    be used as the identity. Otherwise, the (most specific) Common Name
>    field in the Subject field of the certificate MUST be used. Although
>    the use of the Common Name is existing practice, it is deprecated and
>    Certification Authorities are encouraged to use the dNSName instead.


However, the wording in draft-saintandre-tls-server-id-check-03 seems to 
suggest it could really not be acceptable to have the host name in the 
CN at all if it's not in the leaf, irrespectively of whether the CN is 
going to be checked because there's a subjectAltName in this case (it 
somehow depends on the interpretation of "represent" here):

> The certificate MUST NOT represent the server's domain name in an
>        identity of Common Name (CN) where the CN is in something other
>        than the "leaf" (left-most) position within the Relative
>        Distinguished Names (RDNs) of the subjectName.



More fundamentally, this rule would break compatibility with the 
existing specifications (RFC 2818 in the case of HTTPS). While I think 
this draft is a good idea in principle, for harmonising the host name 
verification across protocols and having a few new features, I can't see 
what's wrong with RFC 2818's model in this case.
If non-leaf CN's really is a problem, the draft should make a strong 
case for banning them, as it would introduce further constrains on the 
existing rules, and potentially break compatibility.




Best wishes,

Bruno.


[1] https://ca.grid-support.ac.uk/
[2] http://www.ja.net/services/jcs/index.html