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 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
signature.asc
Description: PGP signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
