Discussing CRL Non-conformance with RFC 5280

404 views
Skip to first unread message

Ryan Dickson

unread,
Apr 5, 2024, 9:56:42 AMApr 5
to public

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 chrome-ro...@google.com).


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/


Reply all
Reply to author
Forward
0 new messages