> This might be overstating the case a little bit. Yes, I agree that “not at all” is overstating things. Revocation is a very complex issue, most absolute statements are probably wrong. “Not a replacement in general” might be a better formulation. It might be a replacement in some use cases, but these use cases would then have quite low requirements on revocation.
I agree that in your example, OCSP stapling with a week-long lifetime for the end-certificate only and a certificate with a week-long lifetime give exactly the same security. But - Certificates with one-week lifetimes is not common and will maybe never be common. It also creates work for both the CA and the device. This is not practical for constrained IoT. CA systems in critical infrastructure often do not use OCSP at all due to the risk of denial-of-service attacks and rely purely on CRLs. - The OCSP stapling example you give is a quite specific example (Web/HTTPS). The level of revocation checking in the example is quite low. For many current IPsec deployments, revocation checking is done daily or several times per day. (D)TLS is often replacing IPsec in virtualized environments. One week is quite a long time and in your example revocation checking is only done for the end-entity certificate. Some systems check the revocation status of all the certificates in the chain. In cases with fraudulently issues certificates, they are often used immediately and a week-long lifetimes (certificates or OCSP responses does not help). - And obviously short-term end-entity certificates do not protect against revoked intermediate or self-issued CA certificates. John From: Uta <uta-boun...@ietf.org> on behalf of Daniel Kahn Gillmor <d...@fifthhorseman.net> Date: Monday, 24 January 2022 at 17:19 To: u...@ietf.org <u...@ietf.org>, tls@ietf.org <tls@ietf.org> Subject: Re: [Uta] [TLS] OCSP in RFC7525bis On Mon 2022-01-24 13:06:13 +0000, John Mattsson wrote: > I think another omission in RFC7525 that should be fixed in RFC7525 is > a discussion on certificate life-times, which is often discussed > together with revocation checking- Short-lived certificates is an > improvement over long-lived certificates, but not at all a replacement > for revocation checking. This might be overstating the case a little bit. If revocation checking is done by OCSP stapling, then the OCSP validity window *is* in effect the duration of a "short-lived certificate". To the extent that a short-lived certificate has the same validity period as an OCSP response, it is indeed a replacement for revocation checking. As an example, the validity window of the stapled OCSP response i see according to the cert i get on port 443 of www.ietf.org<http://www.ietf.org> has this validity window: This Update: Fri Jan 21 01:21:02 UTC 2022 Next Update: Fri Jan 28 00:36:02 UTC 2022 But when i query the OCSP responder directly i get this validity window: This Update: Mon Jan 24 01:21:00 UTC 2022 Next Update: Mon Jan 31 00:36:00 UTC 2022 The week-long range is pretty comon, and a week-long certificate would offer just as much protection against certificate misuse (an adversary misusing a certificate with stapled OCSP could cache the last "good" OCSP response and continue stapling it until it expires). So unless "revocation checking" is defined to mean "out-of-band confirmation with the issuing authority" (which would introduce both latency and privacy concerns, so let's not go there), then a short-lived certificate is indeed a replacement for revocation checking. However, under the current certificate transparency regime, short-lived certificates pose a challenge to CT logs, which scale with the number of certificates issued over a given time period. Replacing every 3-month certificate with a corresponding number of 1-week certificates would increase the size of CT logs by a factor of at least 12 -- probably more, since certificates are generally issued with some overlap to account for server-side work at cert transition and client-side clock skew. So, arguably, the advantage of revocation checking via OCSP stapling over short-lived certificates today has to do with keeping CT logs a manageable size, not with any particular security gain in terms of revocation functionality. --dkg
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
