Subject: [TLS] Would removal of upper bounds of common certificate attributes break TLS?

From: Stefan Santesson <[email-masked]>
Date: Tue, 1 Feb 2022 20:55:02 +0100

Hi,

This issue is currently discussed in the LAMPS WG. The background is
that X.520 removed the size limitations of the common X.520 attributes
in 2008, while they are still enforced in RFC 5280.

I don't want to move this discussion to TSL and I don't want to express
an opinion on the matter in this thread.

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.

Both these facts are being claimed, and I simply wonder if these claims
are is true. Thanks!

-- 
________________
Stefan Santesson

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 1 Feb 2022 12:14:46 -0800

>     b) Require any changes or updates to the TLS standard.

Without taking a position on this particular case...

>From a standards perspective, TLS requires that certificates conform to RFC
5280,
and I would expect that if we were to relax any requirement in 5280, that
would
require that the associated RFC update 8446.

>From a practical perspective, it seems like this creates potential
interoperability
risk because you don't know whether a client enforces these restrictions or
not.
Perhaps one could do a survey of common implementations and see who enforces
the limit and then try to normalize it by measured use levels.

-Ekr

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 1 Feb 2022 15:30:08 -0500

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

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 2 Feb 2022 15:22:00 +0000

And for TLS purposes, this is exactly what the 6125-bis draft says, being discussed in the UTA working group.
https://datatracker.ietf.org/doc/draft-ietf-uta-rfc6125bis/

Comments appreciated.