Re: CVE Request: libesmtp does not check NULL bytes in commonName

[Geoff Keating <geoffk () apple com>]

On 11/03/2010, at 6:58 AM, Brian Stafford wrote:

> I find myself coming back to RFC 2818 being a reasonable choice since it is flexible and (almost) clear, and since 
> HTTPS, as a major user of TLS, is, I assume, well analysed for security implications wrt certificate validation. 
> Is it the case that for STARTTLS in SMTP what we are really interested in is encrypting the data on the wire and 
> authentication is only of secondary importance?  Do we know what the best current practice is among CAs when it comes 
> to issuing certificates for STARTTLS?

The best current practice for CAs is probably expressed in the EV certificate requirements documents, which say that 
there should be no wildcards at all---and after reading this discussion, I think you can see why.

I doubt it makes sense, from a CA perspective, to ever issue a certificate with wildcard(s) anywhere but leftmost.  
Certainly there should never be a certificate which has a wildcard for the top-level (or second-level) domain, as that 
would imply the applicant controls the entire internet, and applicants which actually do control the whole internet 
(Akamai, I'm looking at you) can be issued CA intermediate certificates instead, which are better for auditing and 
control.

STARTTLS is a bit different than HTTPS, because in most SMTP configurations there's a trivial fallback attack (pretend 
to be the other server, and don't offer STARTTLS) so here the confidentiality aspects are the most important, to 
prevent passive sniffing.

Somewhere there's a draft RFC that goes into recommendations for certificate validation in much more detail, but I've 
lost it, and it's a draft and not yet complete.