Re: [certid] Comments on draft-saintandre-tls-server-id-check-04

[ArkanoiD <[e-mail]>]

On Mon, May 31, 2010 at 05:18:17PM +0200, Martin Rex wrote:
> > 
> > example, you a Common Name attribute containing the server's name
> > and if the cert has a subjectAltName, have I 'represented' the
> > server's name in the Common Name or not? I have put it in,
> > I don't expect that someone verifies it there, but still, I have
> > can think I have represented it in two places.
> 
> There is going to be software that will check the CN= RDName of the
> certificate subject name for a match, even when subjectAltName of
> type dNSName are present.  Either because they're fully backwards
> compatible or because they do not check subjectAltNames at all.

Actually it should not, though i do not see any harm in behaving that
way.

> While there have been few implementations checking for multiple
> CN= parts, the guideline in rfc-2818 for subjectAltNames seems
> to be much clearer, that there can be more than one, and more
> than one needs to be checked.

..and multiple CNs are likely to be an error. I'd better reject this
certificate as invalid.
> 
> Example: https://www.entrust.com  
> 
> It contains a CN=www.entrust.com and two subjectAltNames
> type dNSName with the values "www.entrust.com" and "secure.entrust.com"
> 
> And a reasonable, fully backwards compatible approach to server endpoint
> identification would be to check all names for a match sequentially,
> and succeed when any one matches.

But we may safely ignore CN in this case, and that's what we probably intend
to do.