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