Re: [certid] CN fallback

[Peter Saint-Andre <[e-mail]>]

On 3/23/10 8:44 AM, Ludwig Nussel wrote:
> Hi,
> 
> | If and only if the identity set does not include subjectAltName
> | extensions of type dNSName, SRVName, uniformResourceIdentifier (or
> | other application-specific subjectAltName extensions), the client MAY
> | as a fallback check the value of the Common Name (CN)
> 
> What about rewording that to the following?
> 
> | If and only if the certificate does not include any subjectAltName
> | extensions, the client MAY as a fallback check the value of the
> | Common Name (CN)

I don't see a strong reason to change that text. This specification is
about checking domain names, not IP addresses.

As an aside, I must say that I'm tempted to move everything about CNs to
a separate section, or to remove it entirely, because I don't think it's
a best current practice for secure authentication.

> That would avoid having generic implementations look into the CN as
> fallback when it doesn't make sense. iPAddress for example isn't
> specified by the I-D (why anyways?). 

1. Do certification authorities issue certificates to IP addresses? The
ones I work with don't (probably because they base their certification
decision on control over the whois data or reserved email addresses for
a domain name).

2. If so, is that a best current practice for secure authentication? I
don't think so.

3. Users don't expect to connect to "192.0.2.7", they expect to connect
to "example.com". That, at least, is one assumption of this I-D. You are
free to write an I-D that specifies rules for representation and
verification of IP addresses in certificates, but that's out of scope
for this I-D.

> So a conforming implementation
> could use the CN when looking for a hostname even if a
> subjectAltName of type iPAddress is present.

Right. But I don't think that is consistent with your proposed text.

Peter

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