Hi Aaron,
> But no, including the distributionPoint is absolutely not required by RFC > 5280 as long as the CRL includes all revoked unexpired certificates within > its scope. It is not even required by the Mozilla Root Store Policy, as long > as there is no critical IssuingDistributionPoint extension in the CRL. It is > required by X.509, but the whole point of RFC 5280 is that it defines what > portions of X.509 apply to the Web PKI; it does not include that requirement > from X.509. These may be oversights or mistakes, and I agree they should be > changed, but we try very hard to separate intent from actual requirements > here. I’ll quote the relevant passage from RFC 5280 again here for easy reference: “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” My interpretation of this passage is that it is defining the required scope of the CRL in the absence of the distributionPoint field. Namely, all revoked certificates issued by the CA must be contained within the scope of the CRL. However, it sounds like your interpretation is that the CRL must contain all revoked certificates that are within its scope. This sounds tautological or seemingly indicates that it is somehow possible to recursively scope CRLs (i.e., a scope within a scope) by including the distributionPoint field. Can you expand upon how your interpretation would work in practice? Thanks, Corey From: 'Aaron Gable' via dev-security-policy@mozilla.org <dev-security-policy@mozilla.org> Sent: Wednesday, October 12, 2022 12:26 PM To: Corey Bonnell <corey.bonn...@digicert.com> Cc: Andrew Ayer <a...@andrewayer.name>; 'Aaron Gable' via dev-security-policy@mozilla.org <dev-security-policy@mozilla.org> Subject: Re: CRL partitioning and IDPs On Wed, Oct 12, 2022 at 7:07 AM Corey Bonnell <corey.bonn...@digicert.com <mailto:corey.bonn...@digicert.com> > wrote: > A simple fix would be to require that CAs use HTTPS URLs for CRL shards, > though this wouldn't be as strong as relying on indicators within the CRL > itself. I believe including the IDP is the better solution, for three reasons: Definitely agreed, I've been convinced by this thread that including the IDP is the right thing to do. Firstly, compromise of the web server/CDN serving the sharded CRLs would allow an attacker to carry out the substitution attack described in this thread, whereas the use of IDP would require the attacker to compromise the CA's signing infrastructure to suppress the inclusion of the extension. Thus, there is a different level of security in the two approaches. Secondly, using HTTPS for transport raises the possibility of recursive revocation lookups, depending on the certificate chain employed. Lastly, the inclusion of the IDP extension and distributionPoint field in sub-scoped CRLs is a requirement of RFC 5280 and X.509 and thus must be unconditionally included (it is a deviation of the profile to omit it). Given that the inclusion of the IDP is the standard mechanism to prevent exactly the attack described in this thread, it should be employed here as opposed to layering hacky fixes on top of CRLs that do not adhere to the profile. But no, including the distributionPoint is absolutely not required by RFC 5280 as long as the CRL includes all revoked unexpired certificates within its scope. It is not even required by the Mozilla Root Store Policy, as long as there is no critical IssuingDistributionPoint extension in the CRL. It is required by X.509, but the whole point of RFC 5280 is that it defines what portions of X.509 apply to the Web PKI; it does not include that requirement from X.509. These may be oversights or mistakes, and I agree they should be changed, but we try very hard to separate intent from actual requirements here. Aaron -- You received this message because you are subscribed to the Google Groups "dev-security-policy@mozilla.org <mailto: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 <mailto:dev-security-policy+unsubscr...@mozilla.org> . To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAEmnEreuC0JKJo5kOjaYqgPB9zS8xgeM3j0afJ_HcQmkx%3DsEUA%40mail.gmail.com <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAEmnEreuC0JKJo5kOjaYqgPB9zS8xgeM3j0afJ_HcQmkx%3DsEUA%40mail.gmail.com?utm_medium=email&utm_source=footer> . -- 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 on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/DM6PR14MB21862D3D1C436F3B5B94206A92229%40DM6PR14MB2186.namprd14.prod.outlook.com.
smime.p7s
Description: S/MIME cryptographic signature
