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 (Update OpenSSL Extension to Support KEMs - Externals) 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