Hello, As you all know, the new Apple and Mozilla policies for CAs to disclose the locations of CRL-based revocation information became effective this month. One of the options for CAs to provide this CRL-based revocation information is to provide a list of all CRL URLs, which when combined, provide a complete list of revoked certificates for the CRL issuer (CA) in the CCADB "JSON Array of Partitioned CRLs" field.
The issuance of partitioned CRLs is described in some detail in section 5.2.5 of RFC 5280 [1]. This section notes that CAs may partition CRLs any way they see fit. However, there is this requirement when partitioning CRLs: "If the distributionPoint field is absent, the CRL MUST contain entries for all revoked unexpired certificates issued by the CRL issuer, if any, within the scope of the CRL." Although the wording could be improved, this passage is rather clear that the IDP extension with the distributionPoint field (which contains the URI of the CRL, in the WebPKI case) must be included if the CRL is partitioned. X.509 08/2005 (which RFC 5280 profiles), section 8.6.2.2 is even clearer regarding the requirement to include the IDP extension in partitioned CRLs: "If the issuing distribution point field, the AA issuing distribution point field, and the CRL scope field are all absent, the CRL shall contain entries for all revoked unexpired public-key certificates issued by the CRL issuer." Why does all this matter? Including the IDP extension not only aligns the CRL with the RFC 5280 profile, but also provides a security-critical function: it provides sufficient information to Relying Parties so that they can confirm they have retrieved the correct CRL and detect substitution attacks. Without the information carried in the IDP, an on-path attacker could substitute another CRL which doesn't contain a serial number for a certificate that has been revoked, thus allowing the attacker to "hide" the revocation of a certificate. Given that the transport of these CRLs listed in CCADB is plaintext HTTP, such an attack would be feasible and would allow bad actors to tamper with the creation of the "compressed CRLs" that are generated by Apple, Mozilla, or other user agents. This security issue also has been raised several times on the IETF PKIX mailing list [2][3]. It does not appear that there is universal agreement or awareness on the above, based on some CCADB entries that were observed. Given this, I wanted to raise this topic for discussion to ensure that there is universal understanding of the requirements and expectations of Root Programs. Thanks, Corey [1] https://www.rfc-editor.org/rfc/rfc5280#section-5.2.5 [2] https://mailarchive.ietf.org/arch/msg/pkix/sdBe9RXFcot9P23XPW-FiOvV2aM/ [3] https://mailarchive.ietf.org/arch/msg/pkix/qAQHDXOM_Y3xY3te-xR0e7lQLjM/ -- You received this message because you are subscribed to the Google Groups "[email protected]" 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/mozilla.org/d/msgid/dev-security-policy/DM6PR14MB2186A40B8B66FF07EA687FB3925C9%40DM6PR14MB2186.namprd14.prod.outlook.com.
smime.p7s
Description: S/MIME cryptographic signature
