On Monday, 19 May 2025 14:14:03 CEST, Filippo Valsorda wrote:
2025-05-19 13:53 GMT+02:00 Viktor Dukhovni <ietf-d...@dukhovni.org>:
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>:
> 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]
That's good to hear! Sorry for not double-checking.
Since the mldsaNN codepoints also reference a draft, I think
they similarly go to show that it's ok to consider assigned
codepoints stable and there is no need for an RFC. (Which to be
clear I agree with. Go shipped X25519MLKEM768 with IANA-assigned
draft-based codepoints.)
It's reflective of how important those algorithms are and how quickly
implementers want them deployed/available.
At Red Hat we have a general policy of _not_ shipping features until they
are
frozen as RFC documents. PQC is very much an exception to this process.
--
Regards,
Alicja Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
