Aaron Gable wrote: > (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.)
Hi Aaron. Corey began this thread by appealing to RFC5280 and X.509, and I see that you rediscovered my rather ancient PKIX post [1] that pointed out that there's "nothing to stop an RFC5280-compliant CA from partitioning CRLs using arbitrary scopes and always omitting the IDP extension" due to a "defect" in the RFC5280 language. Although this "defect" remains in RFC5280, ISTM that the original X.509 requirement is restored by MRSP section 5.2 [2], which says: "CA operators MUST NOT issue ... partial/scoped CRLs that lack a distributionPoint in a critical issuingDistributionPoint extension" Does this observation cause you to rethink your conclusion? [1] https://mailarchive.ietf.org/arch/msg/pkix/X2EjIzHz7ZqxhlX4M_GfZFku6Xw/ [2] https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#52-forbidden-and-required-practices:~:text=CA%20operators%20MUST%20NOT,a%20critical%20issuingDistributionPoint%20extension). ________________________________ From: dev-security-policy@mozilla.org <dev-security-policy@mozilla.org> on behalf of Andrew Ayer <a...@andrewayer.name> Sent: 07 October 2022 15:01 To: Aaron Gable <aa...@letsencrypt.org> Cc: 'Aaron Gable' via dev-security-policy@mozilla.org <dev-security-policy@mozilla.org>; Corey Bonnell <corey.bonn...@digicert.com> Subject: Re: CRL partitioning and IDPs CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. On Thu, 6 Oct 2022 13:36:03 -0700 "'Aaron Gable' via dev-security-policy@mozilla.org" <dev-security-policy@mozilla.org> wrote: > Ah, that's a good point! > > In Let's Encrypt's particular case, we guarantee that all of our CRL > shards in a given "generation" share the same CRL Number, so > detecting one shard substituted from a previous generation would be > very easy. But I recognize that doing so is not required and could > not be relied upon in the general case. Right. I'm not seeing any way for a client to avoid the attack described by Corey without making assumptions about the CA's practices which might not be true in all cases. So I have to concur with Corey that there is currently a security issue which would allow attackers to tamper with Apple and Mozilla revocation systems. 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. Regards, Andrew -- 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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fa%2Fmozilla.org%2Fd%2Fmsgid%2Fdev-security-policy%2F20221007100135.dbb57df7c258081cac2953f1%2540andrewayer.name&data=05%7C01%7Crob%40sectigo.com%7C2b6603bb81ae4881fd1c08daa86c78e0%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638007481084138290%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=wxvk2aikAMdS%2BKo4yOkkce73iGMrgATyEz%2BzKXvnWQo%3D&reserved=0. -- 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/MW4PR17MB4729AD0DD4D7E4CF3A0EE101AA5F9%40MW4PR17MB4729.namprd17.prod.outlook.com.
