Subject: [TLS] TLS specification clarification in case of client authentication: different CA with DN different only in case

From: devzero2000 <[email-masked]>
Date: Mon, 25 Sep 2017 18:21:07 +0200

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

Note the different (M|m)ountain
)

1 - In one case the server could send both DNs to the client, the client
could choose the one that signed its certificate, and the server would be
able to validate, based on the autority key identier, the client with the
right CA.

2 - In another case, instead, the server chooses to send only one of the
two DNs, probably the first configured, and if that is not the one that
signed the client certificate, the authentication would not continue.

I have seen that some TLS implementations follow both of the behaviors
described and this creates interoperability issues, i think. It should not
be an ambiguous behavior, and it should be clarified.

Opinions ?

Thanks you very much for the attention

Ciao

Elia

---

From: Geoffrey Keating <[email-masked]>
Date: 25 Sep 2017 11:54:52 -0700

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