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.
_______________________________________________
certid mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/certid
