On Sat, 05 Sep 2026 10:05:49 +0000, Timo Poppinga wrote:
> In particular, I'd be interested in opinions on whether provider-based > key support and the KEM API should be addressed in a single RFC or > split into separate proposals. These proposals seem reasonable to me on their own. 1) openssl_pkey_get_details() should just return the algorithm name as OpenSSL gives it to us. And for key generation, we can let pass the algorithm name explicitly in OpenSSL's own terms — right now it's inferred from whatever key happens to be set in the options array, which is a bit indirect. 2) Generic KEM encapsulate/decapsulate. This isn't new — there's an old thread (https://externals.io/message/126392) from a while back where it was basically agreed the functions should exist, but it stalled on naming/signature discussions and nothing ever landed. I doubt anyone objects to the functions themselves, it's really just a matter of picking names and getting it done this time. I'd rather not lump everything into one big RFC — these two feel like they can be handled separately from the PQC discussion. Also, if you need, I'd be happy to help you implement both of these. > I'd like to start a discussion about improving support for modern > OpenSSL provider-based asymmetric algorithms in ext/openssl, in > particular post-quantum cryptography (PQC). As for PQC specifically: I went through ext/openssl against OpenSSL 3.5/4.0's PQC support. Turns out a lot of it already works unmodified — PEM key loading, openssl_sign()/verify(), CSR/certs, CMS on OpenSSL >= 4.0, and X25519MLKEM768-by-default TLS all just work as-is. What's actually missing, and purely additive: - type is now -1 in openssl_pkey_get_details() return value - new parameters support in key generation - TLS group selection/introspection - ML-DSA's context-string/deterministic signing params None of that needs an RFC, going by the Curve25519/448 precedent from 8.4. I'm willing to send these as a handful of small PRs, announced separately, and leave the generic name-based key gen + KEM API in this RFC / RFCs, where Timo's already offering to drive the design. Also drafted tests for the "already works" list, passing on 3.5.8/4.0.2, ready to open. Does that split work for you? The PRs above would target 8.7 (master). -- Thanks, Danilov Alexander
