> 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: 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. Thanks, Corey -----Original Message----- From: dev-security-policy@mozilla.org <dev-security-policy@mozilla.org> On Behalf Of Andrew Ayer Sent: Friday, October 7, 2022 10:02 AM 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 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://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/20221007100135.dbb57df7c258081cac2953f1%40andrewayer.name. -- 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/DM6PR14MB2186663D6051018A3B789B4B92229%40DM6PR14MB2186.namprd14.prod.outlook.com.
smime.p7s
Description: S/MIME cryptographic signature
