On Fri, Feb 26, 2021 at 6:01 PM Aaron Gable <aa...@letsencrypt.org> wrote:
> On Fri, Feb 26, 2021 at 12:05 PM Ryan Sleevi <r...@sleevi.com> wrote: > >> You can still do parallel signing. I was trying to account for that >> explicitly with the notion of the “pre-reserved” set of URLs. However, that >> also makes an assumption I should have been more explicit about: whether >> the expectation is “you declare, then fill, CRLs”, or whether it’s >> acceptable to “fill, then declare, CRLs”. I was trying to cover the former, >> but I don’t think there is any innate prohibition on the latter, and it was >> what I was trying to call out in the previous mail. >> >> I do take your point about deterministically, because the process I’m >> describing is implicitly assuming you have a work queue (e.g. pub/sub, go >> channel, etc), in which certs to revoke go in, and one or more CRL signers >> consume the queue and produce CRLs. The order of that consumption would be >> non-deterministic, but it very much would be parallelizable, and you’d be >> in full control over what the work unit chunks were sized at. >> >> Right, neither of these are required if you can “produce, then declare”. >> From the client perspective, a consuming party cannot observe any >> meaningful difference from the “declare, then produce” or the “produce, >> then declare”, since in both cases, they have to wait for the CRL to be >> published on the server before they can consume. The fact that they know >> the URL, but the content is stale/not yet updated (I.e. the declare then >> produce scenario) doesn’t provide any advantages. Ostensibly, the “produce, >> then declare” gives greater advantage to the client/root program, because >> then they can say “All URLs must be correct at time of declaration” and use >> that to be able to quantify whether or not the CA met their timeline >> obligations for the mass revocation event. >> > > I think we managed to talk slightly past each other, but we're well into > the weeds of implementation details so it probably doesn't matter much :) > The question in my mind was not "can there be multiple CRL signers > consuming revocations from the queue?"; but rather "assuming there are > multiple CRL signers consuming revocations from the queue, what > synchronization do they have to do to ensure that multiple signers don't > decide the old CRL is full and allocate new ones at the same time?". In the > world where every certificate is pre-allocated to a CRL shard, no such > synchronization is necessary at all. > Oh, I meant they could be signing independent CRLs (e.g. each has an IDP with a prefix indicating which shard-generator is running), and at the end of the queue-draining ceremony, you see what CRLs each worker created, and add those to the JSON. So you could have multiple "small" CRLs (one or more for each worker, depending on how you manage things), allowing them to process revocations wholly independently. This, of course, relies again on the assumption that the cRLDP is not baked into the certificate, which enables you to have maximum flexibility in how CRL URLs are allocated and sharded, provided the sum union of all of their contents reflects the CA's state. > This conversation does raise a different question in my mind. The Baseline > Requirements do not have a provision that requires that a CRL be re-issued > within 24 hours of the revocation of any certificate which falls within its > scope. CRLs and OCSP responses for Intermediate CAs are clearly required to > receive updates within 24 hours of the revocation of a relevant certificate > (sections 4.9.7 and 4.9.10 respectively), but no such requirement appears > to exist for end-entity CRLs. The closest is the requirement that > subscriber certificates be revoked within 24 hours after certain conditions > are met, but the same structure exists for the conditions under which > Intermediate CAs must be revoked, suggesting that the BRs believe there is > a difference between revoking a certificate and *publishing* that > revocation via OCSP or CRLs. Is this distinction intended by the root > programs, and does anyone intend to change this status quo as more emphasis > is placed on end-entity CRLs? > > Or more bluntly: in the presence of OCSP and CRLs being published side by > side, is it expected that the CA MUST re-issue a sharded end-entity CRL > within 24 hours of revoking a certificate in its scope, or may the CA wait > to re-issue the CRL until its next 7-day re-issuance time comes up as > normal? > I recall this came up in the past (with DigiCert, [1]), in which "revocation" was enacted by setting a flag in a database (or perhaps that was an *extra* incident, with a different CA), but not through the actual publication and propagation of that revocation information from DigiCert's systems through the CDN. The issue at the time was with respect to 4.9.1.1's requirements of whether or "SHALL revoke" is a matter of merely a server-side bit, or whether it's the actual publication of that revocation within the Repository (as reflected by the CRL). I do believe it's problematic for the OCSP and CRL versions of the repository to be out of sync, but also agree this is an area that is useful to clarify. To that end, I filed https://github.com/cabforum/servercert/issues/252 to make sure we don't lose track of this for the BRs. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1640805 > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
