Thanks for the reminder that CCADB automatically dereferences URLs for archival purposes, and for the info about existing automation! I don't personally have CCADB credentials, so all of my knowledge of it is based on what I've learned from others at LE and from this list.
If we leave out the "new url for each re-issuance of a given CRL" portion of the design (or offer both url-per-thisUpdate and static-url-always-pointing-at-the-latest), then we could in fact include CRLDP urls in the certificates using the rolling time-based shards model. And frankly we may want to do that in the near future: maintaining both CRL *and* OCSP infrastructure when the BRs require only one or the other is an unnecessary expense, and turning down our OCSP infrastructure would constitute a significant savings, both in tangible bills and in engineering effort. Thus, in my mind, the dynamic sharding idea you outlined has two major downsides: 1) It requires us to maintain our parallel OCSP infrastructure indefinitely, and 2) It is much less resilient in the face of a mass revocation event. Fundamentally, we need our infrastructure to be able to handle the revocation of 200M certificates in 24 hours without any difference from how it handles the revocation of one certificate in the same period. Already having certificates pre-allocated into CRL shards means that we can deterministically sign many CRLs in parallel. Dynamically assigning certificates to CRLs as they are revoked requires taking a lock to determine if a new CRL needs to be created or not, and then atomically creating a new one. Or it requires a separate, not-operation-as-normal process to allocate a bunch of new CRLs, assign certs to them, and then sign those in parallel. Neither of these -- dramatically changing not just the quantity but the *quality* of the database access, nor introducing additional processes -- is acceptable in the face of a mass revocation event. In any case, I think this conversation has served the majority of its purpose. This discussion has led to several ideas that would allow us to update our JSON document only when we create new shards (which will still likely be every 6 to 24 hours), as opposed to on every re-issuance of a shard. We'd still greatly prefer that CCADB be willing to accept-and-dereference a URL to a JSON document, as it would allow our systems to have fewer dependencies and fewer failure modes, but understand that our arguments may not be persuasive enough :) If Mozilla et al. do go forward with this proposal as-is, I'd like to specifically request that CCADB surfaces an API to update this field before any root programs require that it be populated, and does so with sufficient lead time for development against the API to occur. Thanks again, Aaron On Fri, Feb 26, 2021 at 8:47 AM Ryan Sleevi <r...@sleevi.com> wrote: > > > On Fri, Feb 26, 2021 at 5:49 AM Rob Stradling <r...@sectigo.com> wrote: > >> > We already have automation for CCADB. CAs can and do use it for >> disclosure of intermediates. >> >> Any CA representatives that are surprised by this statement might want to >> go and read the "CCADB Release Notes" (click the hyperlink when you >> login to the CCADB). That's the only place I've seen the CCADB API >> "announced". >> >> > Since we're talking Let's Encrypt, the assumption here is that the CRL >> URLs >> > will not be present within the crlDistributionPoints of the >> certificates, >> > otherwise, this entire discussion is fairly moot, since those >> > crlDistributionPoints can be obtained directly from Certificate T >> ransparency. >> >> AIUI, Mozilla is moving towards requiring that the CCADB holds all CRL >> URLs, even the ones that also appear in crlDistributionPoints extensions. >> Therefore, I think that this entire discussion is not moot at all. >> > > Rob, > > I think you misparsed, but that's understandable, because I worded it > poorly. The discussion is mooted by whether or not the CA includes the > cRLDP within the certificate itself - i.e. that the CA has to allocate the > shard at issuance time and that it's fixed for the lifetime of the > certificate. That's not a requirement - EEs don't need cRLDPs - and so > there's no inherent need to do static assignment, nor does it sound like LE > is looking to go that route, since it would be incompatible with the design > they outlined. Because of this, the dynamic sharding discussed seems > significantly _less_ complex, both for producers and for consumers of this > data, than the static sharding-and-immutability scheme proposed. > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
