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

From: Alexey Melnikov <[email-masked]>
Date: Mon, 05 Apr 2010 22:34:20 +0100

Peter Saint-Andre wrote:

>On 3/17/10 10:58 PM, ArkanoiD wrote:
>  
>
>>Well, when it comes to implementation we get *two* matching algorithms then,
>>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.
>  
>
+1.

>>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.
>
The short answer is that only the leaf RDN corresponds to the entity to 
which the certificate belongs. Other RDNs can correspond to entities 
that signed the certificate. E.g. if subject name is:

 cn=example.com, o=Certificated, cn=verisign.com, c=US

then it doesn't mean that verisign.com is the entity described by the 
certificate.

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 09 Apr 2010 10:29:53 -0600

Regarding self-signed certs, Alexey and I had the following exchange...

>> self-signed certs. It's not as if any "certification" has taken place in

Someone named "ArkanaoiD" (how's that for identity? :) wrote:

   Well, when it comes to implementation we get *two* matching
   algorithms then, which is definitely no good.

IMHO we don't necessarily get two matching algorithms -- it's just that
the matching algorithm for self-signed certificates is not specified in
this document. Given that we are trying to define best practices for
secure authentication of application services, I don't think it makes a
lot of sense to discuss self-signed certs.

Bruno Harbulot wrote:

   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.

And Bil Corry wrote:

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

Bruno and Bil, would you find it acceptable if this document simply does
not mention self-signed certificates? We really are trying to limit the
scope of this document to a very particular problem, but I'm quite open
to discussing related problems in other documents. However, if it is
going to be more confusing to say that self-signed certs are out of
scope then I'd consider including some text about them.

Peter

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

---

From: Bil Corry <[email-masked]>
Date: Sat, 10 Apr 2010 09:23:33 -0700

> scope then I'd consider including some text about them.

How about the scenario where a company acts as its own CA for internal systems; i.e. their root cert is installed across their entire enterprise and is effectively a CA for those browsers.  Is that in or out of scope for this document? 

- Bil

---

From: Kurt Zeilenga <[email-masked]>
Date: Sun, 11 Apr 2010 16:55:13 -0700

> How about the scenario where a company acts as its own CA for internal systems; i.e. their root cert is installed across their entire enterprise and is effectively a CA for those browsers.  Is that…

I think why a client might choose to trust or not trust a CA is out of scope of the I-D. 

-- Kurt

---

From: Bruno Harbulot <[email-masked]>
Date: Thu, 15 Apr 2010 14:44:07 +0100

Hello,

>> scope then I'd consider including some text about them.

Yes, I think it's probably better to leave trust into the certificate 
itself (self-signed or not) out of the scope of this document. (There 
are other documents for this, including RFC 5280.)

I don't think it makes sense to exclude self-signed certificates as 
such, and I don't agree with the previous quote:
"It's not as if any "certification" has taken place in this situation."
Certification may have taken place, out of bands, like it's the case for 
CA certificates such as Verisign's that end up automatically in most 
browsers (a process that undoubtedly involves some amount of politics). 
There's always a leap of faith to be made for bootstrapping trust. 
Whether one gets a cert (or a certification path to a cert) from a 
friend handing a cert in person or via some vendor's bundled software 
has to be subject to the judgement of the user.

The only specificity of a self-signed server certificate here is that 
the certification path is extremely short.

> How about the scenario where a company acts as its own CA for internal systems; i.e. their root cert is installed across their entire enterprise and is effectively a CA for those browsers.  Is that…

I think this scenario is orthogonal to the scope of this document. It's 
perfectly acceptable for a company to have its own CA and comply with 
this document as well as RFC 5280 (or maybe some other model of PKI).

As far as I read it, the purpose of this I-D is to check that the 
certificate obtained when connecting to server is indeed bound to that 
server and not some other server, not to verify the trust in the 
certificate itself.
As far as I'm aware, most APIs implement these two concerns separately 
anyway.

Just to bring back the self-signed cert issue into context, this 
discussion started with some self-signed certs including e-mail 
addresses as leaf RDNs: having non-CN leaf RDNs was the main point as 
far I understood.
As I was saying then, this is not specific to self-signed certificates. 
I use at least one CA (the UK e-Science CA) that puts e-mail addresses 
in the DN. It appears that its US counterpart does it too: 
http://teragrid.psc.edu/pscCert.php#DN
(This is probably more appropriate for the thread on RDNs.)

Best wishes,

Bruno.

---

From: Michael Ströder <[email-masked]>
Date: Mon, 19 Apr 2010 07:13:56 +0200

Alexey Melnikov wrote:
>>> algorithms then,

Personally I don't want to endorse the use of self-signed certificates but I
fail to see why self-signed certificates should be treated differently
regarding name checking. Self-signed certificate are just treated differently
regarding path validation (e.g. with a fingerprint transferred out-of-band)
but the server name check should be the same.

Ciao, Michael.