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

From: ArkanoiD <[email-masked]>
Date: Wed, 17 Mar 2010 16:43:27 +0300

Subject: Re: [oss-security] CVE Request: libesmtp does not check NULL bytes in commonName
From: Ludwig Nussel <[email-masked]>
To: [email-masked], Brian Stafford <[email-masked]>
Cc: [email-masked], [email-masked], Pawel Salek <[email-masked]>, [email-masked]
Date: Wed, 17 Mar 2010 14:32:58 +0100

ArkanoiD wrote:
> And according to the draft we MUST ignore non-leaf value even if
> it is the only one CN, just incorrectly placed.

Many self-signed certificates seem to have an email address as leaf
RDN. I guess that's because openssl's CA.sh asks for the mail
address. So with that additional constraint the scary warning
dialogs for self-signed certs are going to be even more confusing in
the future.

cu
Ludwig

-- 
 (o_   Ludwig Nussel
 //\   
 V_/_  http://www.suse.de/
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)

email protected and scanned by AdvascanTM - keeping email useful - www.advascan.com

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 17 Mar 2010 21:59:46 -0600

On 3/17/10 7:43 AM, ArkanoiD wrote:

> RDN.

This I-D does not cover self-signed certs, only CA-issued certs.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: ArkanoiD <[email-masked]>
Date: Thu, 18 Mar 2010 07:58:25 +0300

Well, when it comes to implementation we get *two* matching algorithms then,
which is definitely no good ;-). What is the rationale of enforcing CN to
be leaf RDN?

---

From: Joe Orton <[email-masked]>
Date: Thu, 18 Mar 2010 10:10:25 +0000

> dialogs for self-signed certs are going to be even more confusing in

I agree with this; I can't think of any motivation for restricting the 
CN to only the most specific RDN.  To quantify whether or not it happens 
"in the wild", I looked at Johnathan Nightingale's database of SSL 
certs:

  http://blog.johnath.com/2009/01/21/ssl-information-wants-to-be-free/

The "top 10K sites" database has 2986 certs from public servers.  
Breaking down the tag of the most specific ("leaf") RDN in the Subject 
of each cert gives:

TAG         COUNT  % of TOTAL
C               9   0%
CN           2333  78%
emailAddress  596  19%
O               1   0%
OU             31   1%
serialNumber   10   0%
ST              6   0%

The draft looks good otherwise, BTW.

Regards, Joe

---

From: Bruno Harbulot <[email-masked]>
Date: Thu, 18 Mar 2010 11:07:31 +0000

> 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=[email-masked]

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

---

From: Bil Corry <[email-masked]>
Date: Thu, 18 Mar 2010 12:21:07 -0700

> the latter could impose constraints on the former depending on policies).

I agree.  Isn't the distinction between CA-issued certs and self-signed certs more-or-less which CAs you choose to trust?

- Bil

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 31 Mar 2010 15:53:11 -0600

On 3/17/10 10:58 PM, ArkanoiD wrote:
> which is definitely no good ;-). 

Given that a self-signed certificate can say *anything*, I don't know
that it's helpful to enforce any rules about issuance and checking of
self-signed certs. It's not as if any "certification" has taken place in
this situation.

> What is the rationale of enforcing CN to
> be leaf RDN?

As I recall, Alexey Melnikov brought that up so I'll ping him about it.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/