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.
-
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. -
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