> 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: https://externals.io/message/130673 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.
