I am happy to work on the RFC, API design, documentation and testing,
and to help with the implementation where I can. I would particularly
appreciate involvement from someone already working on ext/openssl for
the actual C implementation.I am currently preparing an RFC and would especially appreciate feedback
from people familiar with ext/openssl on the general direction and API
design before finalizing the proposal.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.
Hi Timo,
Sebastian sent an email a while ago with similar motivation. It
unfortunately did not get any traction, but I'm glad this was brought
up again:
Similar to how ext-curl integrates libcurl into PHP, I personally
believe that, ideally, ext-openssl should remain as close as possible
to OpenSSL, without introducing our own APIs. Userland libraries can
abstract the complexities and provide purpose-built and intuitive
APIs. This simplifies our work in the integration, and provides an
easy verification path for ext-openssl development.
ext-openssl not only lacks PQC APIs, but also several other features
and changes introduced in OpenSSL 3.5 and 4. It can be quite a big
task, and I'd be really happy to help in any ways I can too.
Thank you,
Ayesh.