Hi John, thanks for pointing that out. We currently support these code points to be interoperable with the oqs-provider project [1], which initially selected those [2]. If there is a broader desire to register those code points, I think the oqs-provider people should initiate this.
On another note, we are currently in the process of improving our hybrid PQC support, in which these (currently) not to be standardized code points will be disabled by default. Then, only the code points from draft-ietf-tls-ecdhe-mlkem [3] will be enabled by default. Best regards, Tobias [1] https://github.com/open-quantum-safe/oqs-provider [2] https://github.com/open-quantum-safe/oqs-provider/blob/main/oqs-template/oqs-kem-info.md [3] https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/04/ -- Tobias Frauenschläger Software Engineer, wolfSSL +1 (530) 409-2990 https://www.wolfssl.com https://github.com/wolfssl On Thu, 2026-02-12 at 10:48 +0000, John Mattsson wrote: > > Hi, > > > While looking at ClientHellos from various modern TLS > implementations, we noticed that WolfSSL by default includes the > following code points: > > > WOLFSSL_SECP256R1MLKEM512 = 12107, > WOLFSSL_SECP384R1MLKEM768 = 12108, > WOLFSSL_SECP521R1MLKEM1024 = 12109, > WOLFSSL_X25519MLKEM512 = 12214, > WOLFSSL_X448MLKEM768 = 12215, > > > These are in the "specification required" range. My understanding is > that they should have used the "Reserved for Private Use" range or > registered the code points (which is trivial to do by sending an > email referencing a public GitHub repository). > > > Cheers, > John > >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
