TLS With Certificate Management for PVXS

[george-mcintyre]

Cert Management
Stapling
OCSP
Cert Status

[anjohnson]

The OS community looks to be moving away from OCSP, that might mean functionality to support it could eventually be removed from libraries that implement TLS...
https://letsencrypt.org/2024/07/23/replacing-ocsp-with-crls/

[george-mcintyre]

Hiya Andrew.Thanks for the heads up.CRL’s have proven to be an inefficient way of transferring revocation information to clients, however the efficiency has improved dramatically in recent years by having browsers pre-download lists on a regular update basis, commonly six hours, and by the use of sharding to reduce the list sizes in some application domains where possible.  At the same time OCSP has come under attack because malicious actors can snoop the OCSP requests to spy on the browser activity of infected clients. 1. In Secure PV Access our certificate status requests, though now a simple PV, are equally transparent on the network, so are susceptible to the same snooping attack.  However, ALL PV Access searches (Secure or legacy) remain completely transparent on the network in any case.  We may need to address this vulnerability in future, but Secure PV Access deliberately does not.  For the responses, we are using the same signed packaging of OCSP (PKCS#7) but transporting it over PV Access.2. In typical usage scenarios of OCSP we have a browser agent which has persistent, cross-invocation, storage. The large downloads that plagued the implementations of CRL’s in the past were mitigated by the browser agent making frequent updates to its cached list that were independent of user browser activity, so that by the time a user request was made the revocation status of any certificate the request contained would already be known. With Secure PV Access we could use a similar persistent storage location to allow all Secure PV Access clients to share a list of updated certificate revocations. However, unlike in the browser scenario, we don’t have a single “app” that could maintain this list independently of application requests.  Failing this, all initial Secure PV Access requests would have to wait for a new full CRL to be updated in the client storage before a connection could be established.  This is not to say that something couldn’t be proposed. Just that the environments are significantly different. 3. We are using some openssl OCSP functions and macros in our response implementation, so this is indeed of some concern. We will seriously look at moving to directly signing our OCSP responses using the PKCS#7 format which is independent of OCSP, and creating our own payload structure instead of relying on the OCSP functions for packing and unpacking the response. We will continue to monitor this developing issue and see what other changes to the design of Secure PV Access need to be made.  New patterns are constantly being proposed implemented and tested in this respect, so we’ll keep our eyes open.Thanks again for the update.  We’ll look at changing our response processing. George McIntyreThis email and any files transmitted with it are confidential and privileged information, intended solely for the use of the individual or entity to whom they are addressed. Any unauthorised review, use, disclosure or distribution is prohibited. Sent from my iPhoneOn 13 Jan 2025, at 22:49, Andrew Johnson ***@***.***> wrote: The OS community looks to be moving away from OCSP, that might mean functionality to support it could eventually be removed from libraries that implement TLS... https://letsencrypt.org/2024/07/23/replacing-ocsp-with-crls/ —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>