Great to hear it. A few responses inline: > 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
We can take these as requirements. > Qeustions: > - Are you thinking memory-only cache for the OCSP responses or on-disk too? The cache could be implemented as a runtime cache or also a persistent cache. One approach for the interface could be: - CURLOPT_SSL_VERIFYCACHING. Pass 1 to enable runtime caching of OCSP responses. Pass 0 to disable OCSP caching. - CURLOPT_SSL_VERIFYCACHING_LOAD. Pass a data structure to inject a starting cache. - CURLINFO_SSL_VERIFYCACHING_GET. Get a data structure of the cache that can be saved off. This would allow the persistent cache to be implemented by the user application. Another approach for the interface could be: - CURLOPT_SSL_VERIFYCACHING. Pass 1 to enable runtime caching of OCSP responses. Pass 2 to enable persistent caching. Pass 0 to disable OCSP caching. - CURLOPT_SSL_VERIFYCACHING_DIR. Pass a directory to store the OCSP cache into. Pass NULL to disable persistent caching. This would have the OCSP persistent caching implemented within Curl. Thoughts on whether one approach or another would be preferable for curl? One other possibility would be full chain verification - just looping over all the intermediate certificates as well. With regard to your further items: > 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 > - 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? We haven't thought about these yet, but will. As a practical matter, we will start with OpenSSL. > - This is a rather big work. Try to split it up so that commits can be > reviewed without require super humans to do it. We will do our best! Thanks, Van Van Lindberg OSPOCO: Open Source Program Office as a Service v...@ospo.co | 210.201.2024 This message and any attachments may contain privileged or confidential information. All applicable rights and privileges, including attorney-client privilege, are reserved and asserted. If you are not the intended recipient or believe that you have received this communication in error, please do not print, copy, share, or otherwise use the information. ------------------------------------------------------------------- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
