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