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. 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? Agreed - I do think having a well-tested, reliable path for programmatic > update is an essential property to mandating the population. My hope and > belief, however, is that this is fairly light-weight and doable. > Thanks, I look forward to hearing more about what this will look like. Aaron _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
