Should TLS CertificateType incorporate SubjectType?

[davidben]

Right now we have one TLS CertificateType value, bikeshed, for all of BikeshedCertificate. This is good for treating ProofType opaquely, but it also negotiates all SubjectTypes at once.

The SubjectType for TLS is implicitly tls, so that works out. But suppose we needed to define something like. If we build a TLS out of a different key type (e.g. KEMTLS), it'll want a different SubjectType. Or maybe we just decide we need to define tls2 for some reason.

Something like KEMTLS might its own negotiation story anyway, so this may be fine. Something like tls2 would need its own signaling extension. Perhaps we should just rename it to bikeshed_tls which is BikeshedCertificate + SubjectType = tls. And then other SubjectTypes intended for use with TLS just get their own corresponding CertificateType values.

[bwesterb]

In the current ~KEMTLS~ AuthKEM draft it's negotiated by assigning signature_algorithms codepoints to KEMs. That would just work with MTC: no need to do something special. I'm afraid I do not see an advantage of a separate SubjectType, except for elegance.

@thomwiggers What's your take?

[thomwiggers]

I'm not exactly read into the MTC draft yet; but I can maybe help clarify why AuthKEM reuses the signature_algorithms codepoint:

1. In our view, signature_algorithms covers authentication algorithms and controls switching between them; AuthKEM introduces new authentication algorithms.
2. Reusing it was easier in my own implementations.
3. Reusing it avoids having to decide and specify preference between an AuthKEM extension and "legacy" signature_algorithms

For these reasons, if AuthKEM is standardized, I expect this to stay the same.

I'm not exactly sure what the SubjectType and CertificateType impose in terms of security or negotiation expectations?

[thomwiggers]

I read a bit further and these are my very, very rough thoughts. I may be missing the mark here, but I'm still sharing them because if wrong I still hope that the way I misread things can be instructive 😄

Skimming the draft, I am getting the impression that it does indeed seem that the CertifiateType and SubjectType are currently very related, and it seems unlikely that the same certificate may be used for different purposes (which I guess is already sort of the case with certificates because they specify EKUs?). The suggestion in the text to just add new certificate types to TLS if that becomes necessary (i.e., bikeshed_tls2) seems very reasonable.

In terms of implementing that in TLS, I would expect that this might also be easier; I imagine that a new SubjectType requires branching of the certificate handling anyway, so branching on CertificateType might be just as easy?