Re: [certid] open issue: self-signed certs

[Bruno Harbulot <[e-mail]>]

Hello,

Bil Corry wrote:
> Peter Saint-Andre wrote on 4/9/2010 9:29 AM: 
>> Regarding self-signed certs, Alexey and I had the following exchange...
>>
>> On 4/5/10 3:34 PM, Alexey Melnikov wrote:
>>> Peter Saint-Andre wrote:
>>>
>>>> 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.
>> 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.

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 in or out of scope for this document? 

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.