Should TLSSubjectInfo have an extension list?

[bwesterb]

If the extension is critical, then it is undeployable without some form of negotiation. If there is negotiation, then instead we can simply negotiate a TLSSubjectInfo2 via bikeshed_tls2, cf #7.

So, which non-critical extensions could we imagine requiring in the future?

[davidben]

The one (very, very speculative) use case I keep tossing around my head is a downgrade protection scheme.

Imagine if some site needs to mint both TLSSubjectInfo and TLSSubjectInfo2. Let's say we designed this back in time and TLSSubjectInfo is like RSA key exchange or SSL 2.0 or something horrid like that. As a server, you don't want modern clients to be vulnerable to those algorithms. But the old clients aren't gone yet, so you still need to have TLSSubjectInfo around. Conversely, the old servers aren't all upgraded, so the new clients still need to support the old protocols.

Or even within TLSSubjectInfo, perhaps we're in a PQ transition state where you have both an RSA TLS key and a Dilithium TLS key, and clients support both.

We'd like for the modern clients to reject the modern server's weak credential, because they should only ever be presented with the strong credential. One way to solve this is a non-critical extension (or, equivalently, a critical extension we define today) that means "distrust this if you understand TLSSubjectInfo2" or "distrust this if you understand Dilithium". The old clients would ignore this, while the new clients would recognize it and follow the instructions.

(All that said, this could just be a Claim rather than a field inside TLSSubjectInfo. It's just kinda weird because the CA isn't really validating anything about this Claim. Their only responsibility is to faithfully put in what the subscriber wanted.)

[bwesterb]

The one (very, very speculative) use case I keep tossing around my head is a downgrade protection scheme.

That's a very good idea. I think we should include that by default. #54