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
