On Tue, Feb 01, 2022 at 08:55:02PM +0100, Stefan Santesson wrote:
> However, I'm curious about the facts of the case, and would appreciate
> if people here could help me answer a key question:
>
> - Would removal of such upper bounds (e.g. common name max 64
> characters) break TLS in any way such as:
>
> a) Breaking current implementations
>
> b) Require any changes or updates to the TLS standard.
To the extent that most certificates have SANs these days, and
implementations are expected to ignore the subject DN when a supported
SAN is present, changes in the limits on CommonName should be of little
consequence.
It should perhaps be noted that best practice is to not bother with a
subject DN at all (setting it to an empty sequence) when an appropriate
SAN is included in the certificate.
Thus, while the low limits are a bit of a nuisance, in a way they're
a feature not a bug, in that they encourage avoiding the subject DN
entirely.
Yes, I have implemented signers that set the CommonName if short enough,
and leave the subject DN empty otherwise, but it would have been even
better to just always leave it empty.
CommonName aside, what are the other use-cases of interest for revising
limits?
One place I'd search for interoperability issues would be in various
MiTM gateway proxies that resign the externally presented certificate
largely verbatim, after replacing the public key (and ideally setting a
short expiration). These might fail if presented with out of spec
CommonName values.
That is, I'd expect more friction in code that creates certificates than
in code that cosumes them.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
