On Thu, Oct 6, 2022 at 10:09 AM 'Corey Bonnell' via [email protected] <[email protected]> wrote:
> > > 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. > While I agree with the analysis of the security risk in the historical usage of CRL URLs embedded in certificates, I do not agree with the above interpretation of RFC 5280 and do not believe that the security analysis applies in the modern context of CRL URLs consumed by root programs from CCADB. (Full disclosure: Let's Encrypt does not currently include the Issuing Distribution Point extension, and therefore does not include its distributionPoint field, in its CRLs. This is because we conducted the analysis laid out below and came to the conclusion that it is not required.) As Corey quoted, RFC 5280 Section 5.2.5 says that the CRL must cover "all revoked unexpired certificates... within the scope of the CRL". Section 5 defines the scope of a CRL: > Each CRL has a particular scope. The CRL scope is the set of > certificates that could appear on a given CRL. For example, the > scope could be "all certificates issued by CA X", "all CA > certificates issued by CA X", "all certificates issued by CA X that > have been revoked for reasons of key compromise and CA compromise", > or a set of certificates based on arbitrary local information, such > as "all certificates issued to the NIST employees located in > Boulder". It's clear from this definition that a scope is not required to be something representable within the fields of the CRL itself (e.g. "employees in Boulder"), nor something representable within the fields of the certificate itself (e.g. "revoked for reason X"). The Let's Encrypt CRL shards have the scope "all certificates issued by CA X with notAfter timestamps between Y and Z". This is a fairly straightforward scope. Since the CRLs *do* contain entries for all revoked unexpired certificates within that scope, they are not required to contain the distributionPoint field, as per RFC 5280 Section 5.2.5. The argument that the distributionPoint field should be present anyway due to the protection it provides against replacement attacks was compelling in the time when CRL URLs were included in certificates and fetched directly by clients. But it does not apply when the CRLs are only intended for consumption by root programs and researchers who are downloading the full collection of CRL shards disclosed in CCADB. An on-path attacker can only replace a CRL shard with another CRL shard issued by the same issuer, which was valid for some particular scope at some particular time (perhaps in the past). A client downloading the full collection of CRL shards can check the thisUpdate timestamps to ensure it is not receiving old data, and can check for duplicate shards to ensure it doesn't receive the same shard twice. As long as they download the correct expected number of sufficiently-recent shards, there are no duplicates, and all signatures validate, they can be confident that none of the shards have been replaced. If we want to make the IDP extension and its distributionPoint field to be mandatory for all sharded CRLs, that makes plenty of sense and is fine by me. I think it is totally reasonable to conclude that RFC 5280's "within the scope of the CRL" language is a bug. As Rob Stradling said in the IETF mail thread Corey linked[1]: "Time for a defect report for RFC5280?". But today (11 years later!) the text is still there, and clearly means that a CRL which covers all certificates within its scope does not need an IDP extension. Aaron [1] https://mailarchive.ietf.org/arch/msg/pkix/X2EjIzHz7ZqxhlX4M_GfZFku6Xw/ -- 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/CAEmnErfT1djCd0XZXKL725eeGMYaZRGh3npi%2B2i5g0pCvDNoHA%40mail.gmail.com.
