Hugely useful! Thanks for sharing - this is incredibly helpful. I've snipped a good bit, just to keep the thread small, and have some further questions inline.
On Thu, Feb 25, 2021 at 2:15 PM Aaron Gable <aa...@letsencrypt.org> wrote: > I believe that there is an argument to be made here that this plan > increases the auditability of the CRLs, rather than decreases it. Root > programs could require that any published JSON document be valid for a > certain period of time, and that all CRLs within that document remain > available for that period as well. Or even that historical versions of CRLs > remain available until every certificate they cover has expired (which is > what we intend to do anyway). Researchers can crawl our history of CRLs and > examine revocation events in more detail than previously available. > So I think unpacking this a little: Am I understanding your proposal correctly that "any published JSON document be valid for a certain period of time" effectively means that each update of the JSON document also gets a distinct URL (i.e. same as the CRLs)? I'm not sure if that's what you meant, because it would still mean regularly updating CCADB whenever your shard-set changes (which seems to be the concern), but at the same time, it would seem that any validity requirement imposes on you a lower-bound for how frequently you can change or introduce new shards, right? The issue I see with the "URL stored in CCADB" is that it's a reference, and the dereferencing operation (retrieving the URL) puts the onus on the consumer (e.g. root stores) and can fail, or result in different content for different parties, undetectably. If it was your proposal to change to distinct URLs, that issue would still unfortunately exist. If there is an API that allows you to modify the JSON contents directly (e.g. a CCADB API call you could make with an OAuth token), would that address your concern? It would allow CCADB to still canonically record the change history and contents, facilitating that historic research. It would also facilitate better compliance tracking - since we know policies like "could require that any published JSON" don't really mean anything in practice for a number of CAs, unless the requirements are also monitored and enforced. > Regardless, even without statically-pathed, timestamped CRLs, I believe > that the merits of rolling time-based shards are sufficient to be a strong > argument in favor of dynamic JSON documents. > Right, I don't think there's any fundamental opposition to that. I'm very much in favor of time-sharded CRLs over hash-sharded CRLs, for exactly the reasons you highlight. I think the question was with respect to the frequency of change of those documents (i.e. how often you introduce new shards, and how those shards are represented). There is one thing you mentioned that's also non-obvious to me, because I would expect you already have to deal with this exact issue with respect to OCSP, which is "overwriting files is a dangerous operation prone to many forms of failure". Could you expand more about what some of those top-concerns are? I ask, since, say, an OCSP Responder is frequently implemented as "Spool /ocsp/:issuerDN/:serialNumber", with the CA overwriting :serialNumber whenever they produce new responses. It sounds like you're saying that common design pattern may be problematic for y'all, and I'm curious to learn more. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
