Hello,

While recently evaluating open-source linting tools against the Certificate
Revocation Lists (CRLs) disclosed to the Common CA Database (CCADB)[1], we
identified several instances of CRLs issued by publicly-trusted CA Owners
that do not conform to RFC 5280.

At this time, CRL non-conformance with RFC 5280 represents a violation of
the CA/Browser Forum TLS Baseline Requirements as described in Section 7.2
[2], but the expectations of the other Baseline Requirements documents do
not appear as well-specified ([3] and [4]).

Evaluating expectations of RFC 5280:


   -

   Section 5.1.2.6 [5] of RFC 5280 states, “When there are no revoked
   certificates, the revoked certificates list MUST be absent.”



   -

   While the ASN.1 representation in Section 5.1 [6] indicates the
revokedCertificates
   field is optional, this cannot be interpreted as superseding the
   requirements described in Section 5.1.2.6 (above).


Note: It’s possible that as we continue studying this area, we’ll identify
and share other findings. Others should feel welcome to do the same.

We wanted to share the outcome of this work to:


   -

   promote broader alignment with RFC 5280.
   -

   encourage other organizations, communities, and working groups (e.g.,
   members of the S/MIME or Code Signing Working Groups of the CA/Browser
   Forum) to consider improving specificity within their respective policies
   to more clearly set expectations regarding CRL profiles.
   -

   highlight the expectations of the TLS BRs, especially given some CA
   Owners may observe future non-conformance after existing entries fall off
   CRLs (i.e., their CRL profile may be problematic, despite CRLs not being
   non-conformant at the time of evaluation). CA Owners should review CRL
   profiles and configurations, where appropriate.


Studying revocation, particularly CRLs, continues to be a point of interest
for our team. We’ve recently begun an experiment in the Chrome Canary and
Dev release channels that adds a subset of leaf certificate revocations to
CRLSet [7] for CRLs disclosed to the CCADB, and hope to share more on this
work and any potential outcomes in the future.

If there are any questions, please let us know (either here, or at
[email protected]).

Thanks,

Ryan (on behalf of the Chrome Root Program)

[1]
https://ccadb.my.salesforce-sites.com/ccadb/AllCertificateRecordsCSVFormatv2

[2]
https://cabforum.org/working-groups/server/baseline-requirements/requirements/#72-crl-profile

[3] https://cabforum.org/working-groups/smime/requirements/#72-crl-profile

[4]
https://cabforum.org/working-groups/code-signing/requirements/#72-crl-profile

[5] https://datatracker.ietf.org/doc/html/rfc5280#section-5.1.2.6

[6] https://datatracker.ietf.org/doc/html/rfc5280#section-5.1

[7] https://www.chromium.org/Home/chromium-security/crlsets/

-- 
You received this message because you are subscribed to the Google Groups 
"CCADB Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/a/ccadb.org/d/msgid/public/CADEW5O_fqy%3Dsf2CzctVkC0XOLx%2Bvx%2B6cj2nJZ1L2t-QdT%3DP73g%40mail.gmail.com.

Reply via email to