[TLS] Re: Erlang/OTP and Bouncy Castle now supporting SLH-DS A in end-entity certificates

On Thu, Aug 13, 2026 at 10:34:06AM +0000, John Mattsson wrote:

> We constantly try to maintain an overview of what different TLS
> libraries support, especially now that we are in the middle of the PQC
> migration.
> 
> While several TLS libraries have supported SLH-DSA in CA certificates
> for some time, I’m happy to report that both Erlang/OTP [1] and Bouncy
> Castle now support SLH-DSA as the public key in end-entity
> certificates. They also support ML-DSA and ML-KEM. SLH-DSA performance
> is adequate for all of our telecom use cases.

Are these enabled by default, or merely available when explicitly
configured on both ends?

> Have I missed any other TLS libraries with comparable support?

The signing performance of SLH-DSA makes it a generally poor choice
for TLS on the public Internet.  Which SLH-DSA variants do you
consider as viable for deployment in TLS?  On an Apple M3:

    CPUINFO: OPENSSL_armcap=0x987d
                         keygens/s    sign/s  verify/s
      SLH-DSA-SHA2-128f     7050.0     300.5    4716.4
      SLH-DSA-SHA2-192f     5055.5     164.7    3095.5
      SLH-DSA-SHA2-256f     1845.0      77.1    2894.5
     SLH-DSA-SHAKE-128f     1405.5      59.2    1010.0
     SLH-DSA-SHAKE-192f      952.0      37.0     657.7
     SLH-DSA-SHAKE-256f      359.7      17.8     684.0
      SLH-DSA-SHA2-128s      110.0      14.4   14140.0
      SLH-DSA-SHA2-192s       80.1       6.9    8001.5
      SLH-DSA-SHA2-256s      116.4       6.9    5455.5
     SLH-DSA-SHAKE-128s       22.1       2.9    2733.5
     SLH-DSA-SHAKE-256s       22.7       1.9    1324.5
     SLH-DSA-SHAKE-192s       14.7       1.6    1958.3

The IANA code points are:

    https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-signaturescheme

    0x0911 	slhdsa_sha2_128s 	N 	[draft-reddy-tls-slhdsa-01] 	
    0x0912 	slhdsa_sha2_128f 	N 	[draft-reddy-tls-slhdsa-01] 	
    0x0913 	slhdsa_sha2_192s 	N 	[draft-reddy-tls-slhdsa-01] 	
    0x0914 	slhdsa_sha2_192f 	N 	[draft-reddy-tls-slhdsa-01] 	
    0x0915 	slhdsa_sha2_256s 	N 	[draft-reddy-tls-slhdsa-01] 	
    0x0916 	slhdsa_sha2_256f 	N 	[draft-reddy-tls-slhdsa-01] 	
    0x0917 	slhdsa_shake_128s 	N 	[draft-reddy-tls-slhdsa-01] 	
    0x0918 	slhdsa_shake_128f 	N 	[draft-reddy-tls-slhdsa-01] 	
    0x0919 	slhdsa_shake_192s 	N 	[draft-reddy-tls-slhdsa-01] 	
    0x091A 	slhdsa_shake_192f 	N 	[draft-reddy-tls-slhdsa-01] 	
    0x091B 	slhdsa_shake_256s 	N 	[draft-reddy-tls-slhdsa-01] 	
    0x091C 	slhdsa_shake_256f 	N 	[draft-reddy-tls-slhdsa-01]

The code points are easy enough to add, but I'm reluctant to enable them
by default.  And unlike the case with supported groups OpenSSL for now
does not have a default supported signature algorithms list that would
exclude these if advertised as TLS signature algorithms by a "provider".

So I'd probably first want to set an explicit signature algorithms list
in the default configuration file that limits the signature algorithms
list to a widely used "sensible" subset, before adding support for
SLH-DSA.

-- 
    Viktor.  🇺🇦 Слава Україні!

_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]