On Thu, Feb 25, 2021 at 12:33 PM Aaron Gable via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> Obviously this plan may have changed due to other off-list conversations, > but I would like to express a strong preference for the original plan. At > the scale at which Let's Encrypt issues, it is likely that our JSON array > will contain on the order of 1000 CRL URLs, and will add a new one (and age > out an entirely-expired one) every 6 hours or so. I am not aware of any > existing automation which updates CCADB at that frequency. > > Further, from a resiliency perspective, we would prefer that the CRLs we > generate live at fully static paths. Rather than overwriting CRLs with new > versions when they are re-issued prior to their nextUpdate time, we would > leave the old (soon-to-be-expired) CRL in place, offer its replacement at > an adjacent path, and update the JSON to point at the replacement. This > process would have us updating the JSON array on the order of minutes, not > hours. This seems like a very inefficient design choice, and runs contrary to how CRLs are deployed by, well, literally anyone using CRLs as specified, since the URL is fixed within the issued certificate. Could you share more about the design of why? Both for the choice to use sharded CRLs (since that is the essence of the first concern), and the motivation to use fixed URLs. We believe that earlier "URL to a JSON array..." approach makes room for > significantly simpler automation on the behalf of CAs without significant > loss of auditability. I believe it may be helpful for the CCADB field > description (or any upcoming portion of the MRSP which references it) to > include specific requirements around the cache lifetime of the JSON > document and the CRLs referenced within it. Indirectly, you’ve highlighted exactly why the approach you propose loses auditability. Using the URL-based approach puts the onus on the consumer to try and detect and record changes, introduces greater operational risks that evade detection (e.g. stale caches on the CAs side for the content of that URL), and encourages or enables designs that put greater burden on consumers. I don’t think this is suggested because of malice, but I do think it makes it significantly easier for malice to go undetected, for accurate historic information to be hidden or made too complex to maintain. This is already a known and, as of recent, studied problem with CRLs [1]. Unquestionably, you are right for highlighting and emphasizing that this constrains and limits how CAs perform certain operations. You highlight it as a potential bug, but I’d personally been thinking about it as a potential feature. To figure out the disconnect, I’m hoping you could further expand on the “why” of the design factors for your proposed design. Additionally, it’d be useful to understand how you would suggest CCADB consumers maintain an accurate, CA attested log of changes. Understanding such changes is an essential part of root program maintenance, and it does seem reasonable to expect CAs to need to adjust to provide that, rather than give up on the goal. [1] https://arxiv.org/abs/2102.04288 > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
