OpenSSL 3.5 added support for SLH-DSA but, as Viktor has already said, that did not include TLS codepoints.
Peter From: tirumal reddy <kond...@gmail.com> Sent: 20 May 2025 10:44 To: tls@ietf.org Subject: [TLS] Re: WG Adoption Call for Use of SLH-DSA in TLS 1.3 On Mon, 19 May 2025 at 17:24, Viktor Dukhovni <ietf-d...@dukhovni.org<mailto:ietf-d...@dukhovni.org>> wrote: On Mon, May 19, 2025 at 01:29:40PM +0200, Filippo Valsorda wrote: > 2025-05-19 12:41 GMT+02:00 John Mattsson > <john.matts...@ericsson.com<mailto:john.matts...@ericsson.com>>: > > OpenSSL 3.5 has already shipped with the Values 0x0911 - 0x91C that > > are in the draft. > > Frankly, this is a bit irritating, especially given the precedent of > seed encodings, where we all got saddled with a fractal encoding to > appease the "legacy" of a handful of early adopters. Now OpenSSL ships > a production feature in a LTS version with 12 commandeered > unregistered codepoints from the public range. Ok. OpenSSL 3.5 DOES NOT have TLS codepoints for SLH-DSA. I don't know where John Mattsson got that impression. The only PQ signature TLS codepoints in OpenSSL 3.5 are: https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-signaturescheme 0x0904 mldsa44 N [draft-tls-westerbaan-mldsa-00] 0x0905 mldsa65 N [draft-tls-westerbaan-mldsa-00] 0x0906 mldsa87 N [draft-tls-westerbaan-mldsa-00] I see that OpenSSL 3.5 supports SLH-DSA (https://openssl-foundation.org/post/2025-04-08-openssl-35-final-release/), but it is not clear which codepoints are used, as they have not yet been assigned by IANA. -Tiru -- Viktor. _______________________________________________ TLS mailing list -- tls@ietf.org<mailto:tls@ietf.org> To unsubscribe send an email to tls-le...@ietf.org<mailto:tls-le...@ietf.org>
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org