> This may be stating the totally obvious, but: this only works for certificates with CRLs.
There's a requirement for CA operators to disclose CRL(s) in CCADB for each CA that they operate such that all issued certificates are in the scope of the disclosed CRLs. This allows for CRL-based revocation information to be available for all certificates, regardless of whether there is a CRL Distribution Points extension in the certificate itself. I haven't poked around the CRLite codebase to see whether it is consuming this information, but it should be possible in theory. Thanks, Corey On Friday, June 20, 2025 at 6:44:33 AM UTC-4 Bas Westerbaan wrote: > When computing the filter, CRLite crucially requires knowledge of all > certificates issued. For this it uses certificate transparency. With the > full list of certificates, when computing the filter, we can check OCSP for > those CAs that don't publish CRLs. I do not know if it's also done, but I'm > sure John will clarify. > > Best, > > Bas > > On Fri, Jun 20, 2025 at 10:12 AM Hanno Böck <ha...@hboeck.de> wrote: > >> Hi, >> >> I recently observed something about certificate revocation that is, in >> retrospect, quite obvious, but I'm not sure if people in the WebPKI >> community are widely aware of it. >> >> As most on this list probably know, most browsers have moved away from >> using revocation checks via OCSP and use aggregated CRL lists like >> Mozilla's CRLite. >> >> This may be stating the totally obvious, but: this only works for >> certificates with CRLs. >> We are currently seeing a mixture of practices. Some CAs have only >> CRLs, some have only OCSP, and some have both. >> >> If a certificate without a CRL is revoked, it is quite possible that a >> cert gets revoked, yet is still in use,and most users will not notice >> it. >> >> CAs that currently do not have CRLs referenced in their certs may want >> to consider that. >> >> Browsers may want to consider better documenting this limitation. >> (E.g., there's a FAQ for CRLite, and I think you can read it between >> the lines, but adding an explicit "What about certificates without a >> CRL?" may be a good idea: >> https://github.com/mozilla/crlite/wiki >> ) >> >> One could also consider having a requirement for CRLs in certificates >> by browser root stores. (I don't have a strong opinion on whether that's >> a good idea.) >> >> -- >> Hanno Böck - Independent security researcher >> https://itsec.hboeck.de/ >> https://badkeys.info/ >> >> -- >> You received this message because you are subscribed to the Google Groups >> "dev-secur...@mozilla.org" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to dev-security-po...@mozilla.org. >> To view this discussion visit >> https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/20250620101221.0b8fc555%40hboeck.de >> . >> > -- You received this message because you are subscribed to the Google Groups "dev-security-policy@mozilla.org" group. To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-policy+unsubscr...@mozilla.org. To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/ff770886-09da-43d1-8eca-a687685ad385n%40mozilla.org.
