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

["Henry B. Hotz" <[e-mail]>]

This looks to me like a case of "violent agreement".

On May 31, 2010, at 11:58 AM, ArkanoiD wrote:

> 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.

His observation was not w.r.t. what SHOULD happen, but a pragmatic observation of what WILL happen in the real world.

>> 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.

He says there are "few" implementations that accept what you consider an error.  Possibly there are zero, but I hope it's few enough we can ignore them.  (Life's complex enough as it is.)

>> 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.

Agreed.

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[e-mail], or [e-mail]