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

Reply via email to