On Fri, 23 Apr 2021, VanL via curl-library wrote:
We would like to expand Curl's support for OCSP verification beyond OCSP stapling to include online OCSP.
We wanted to get commentary on this as a feature, as well as the proposed flow, before creating an issue with a proposed pull request.
Awesome! I was previously in conversations with a customer about OCSP as well, so I've had a chance to think about this already before.
If I would add something already now to your little "requirement spec" it would probably be:
- cutomizable timeout for the OCSP response for when someone drops all the packets to that server - possibly an option of how to act on such time-outs (abort or continue) - decent error reporting so that users can figure out what went wrong when a connection is rejected Challenges I think you might find in your road to landing this: - tests - I propose you try to write this with functions that can be unit-tested - don't bury yourself in a single TLS library's ways of doing things so that there's a chance for other TLS backends to follow suit later on (because I just presume you'll aim at doing this work for a single TLS library first) - needless to say perhaps, but everything needs to be done non-blocking Qeustions: - Are you thinking memory-only cache for the OCSP responses or on-disk too? - For the OCSP caching, will you parse HTTP caching headers for that? - Considered a CURL_LOCK_DATA_OCSP to share OCSP details between easy handles? Proposal: - This is a rather big work. Try to split it up so that commits can be reviewed without require super humans to do it. Good luck! -- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://www.wolfssl.com/contact/ ------------------------------------------------------------------- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
