I'm in agreement with Corey here. The IDP URL must be present in sharded CRLs (i.e. if a CRL is not a complete CRL for the entire CA). I'm also inclined to say HTTPS must not be used here. There are cases where it could work, others where it could cause issues, but overall I don't believe it brings sufficient benefit to be worth outlining the allowance. Further, it's probably worth noting that CRL URL(s) referenced only in the CCADB JSON array should match the IDP URL(s).
Cheers, Clint > On Oct 12, 2022, at 7:07 AM, 'Corey Bonnell' via > dev-security-policy@mozilla.org <dev-security-policy@mozilla.org> 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: > > 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. -- 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/71AA3CBA-C335-4BB8-8D3F-34588615CFA0%40apple.com.
smime.p7s
Description: S/MIME cryptographic signature
