On Tue, May 20, 2025 at 3:10 PM Viktor Dukhovni <ietf-d...@dukhovni.org> wrote:
> On Tue, May 20, 2025 at 07:31:23PM +0200, Alicja Kario wrote: > > > I would like to point out that we need the same kind of codepoints no > matter > > if we want to use SLH-DSA in the end entity certificates or in CA > > certificates. > > This assumes that one bothers signalling support for certificate > signature algorithms separately from TLS signature algorithms. AFAIK, > that's rarely done in practice. If SLH-DSA is not enabled for signing > the certiificate verify message, I don't expect to see it supported in > CA certificates either, at least in the near term. > There is some precedent in TLS to defining codepoints that are only meaningful in the context of CertificateVerify vs X.509. rsa_pkcs1_* in TLS 1.3 may be sent in signature_algorithms, but they implicitly only signal anything in the certificate chain. If the intent is to solve *that* problem, that may be a better way to slice it. Better to avoid an attractive nuisance for folks who see "conservative post-quantum signature algorithm" and miss the blinking neon sign that says "THIS IS NOT FOR ONLINE PROTOCOLS!!!" But yeah, as Viktor notes, the X.509 signature algorithm negotiation parts of TLS have been... questionably successful. It only matters if the authenticating party has two certificates, one rooted in SLH-DSA and another rooted in some other algorithm, and needs to distinguish between relying parties. But this doesn't fully capture the picture anyway because it's not enough to support SLH-DSA roots in the abstract. You have to specifically support *this* SLH-DSA root, and once you've negotiated that, the algorithm parts may as well be implicit. David
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
