devzero2000 <pinto.e...@gmail.com> writes: > Hello everyone > > >From the tls 1.2 specification, speaking of client authentication, > https://tools.ietf.org/html/rfc5246#section-7.4.4 par 7.4.4 (but it is the > same for the last tls draft 1.3 par. 4.2.4.) > > when he says: > > certificate_authorities > A list of the distinguished names [X501] of acceptable > certificate_authorities, represented in DER-encoded format. > > What would be the right behavior if the server has the certificates of two > different CAs (different subject key info, public key parameter) but whose > subject DN differs only for the case (for example > something like this > > Subject: /C=US/ST=California/L=Mountain View/O=XXX Inc/CN=mail.xxx.com > > and > > > Subject: /C=US/ST=California/L=mountain View/O=XXX Inc/CN=mail.xxx.com
These are the same distinguished name under RFC 5280 section 7.1, although in practice implementations may treat them as different, most notably under the older RFC 3280 rules. I believe the correct behaviour is to Not Do That---do not generate certificates which have distinguished names that match under RFC 5280 and are not byte-for-byte identical in DER format, if you must do that make sure they are not valid at the same time, and if you must do that, try to ensure no piece of software is aware of both of them, and if you must do that, don't be surprised if the behaviour is inconsistent and especially don't be surprised if the LDAP StringPrep rules are not implemented correctly or at all. And if you value your sanity, don't rely on anything that might change if the Unicode standard is revised. However, the TLS specification doesn't say that the list must contain each DN only once. So in this situation I would suggest the software should list both. Indeed I would recommend listing every distinct DER representation that's present in any acceptable certificate. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
