On Tue, May 23, 2017 at 9:49 AM, Eran Messeri <[email protected]> wrote:
> > > On Tue, May 23, 2017 at 2:26 PM, Ryan Sleevi <[email protected]> wrote: > >> A variation of this to consider: >> >> - CAs already MUST update their OCSP responses on a 3.5 day interval (by >> virtue of Microsoft's program requirements), which I'm working on codifying >> with the Baseline Requirements since they are, effectively, a baseline that >> Microsoft has defined >> >> A UA could define that: >> - CAs MUST include the SCT and an inclusion proof from that SCT to one of >> the 'blessed' STHs >> > In the OCSP response, I assume? > Yes, apologies :) > - There is a rolling two week window of 'blessed' STHs (using whatever >> selection scheme appropriate) >> >> Whether this is the opt-in server basis or for all connections, this >> could provide a privacy-preserving proof-of-inclusion with stronger >> guarantees. This is built on existing 6962-bis primitives (AIUI), and >> simply an exercise in UA policy. Further, this does not inhibit nor >> substantially change the implementation story for other user agents - which >> could still support other forms of SCT delivery (e.g. precerts, TLS) with >> asynchronous inclusion proof checking. >> > Seems to me like a simpler way to achieve the same requirements, and so > favourable. It does depend on clients fetching OCSP responses / OCSP > stapling by servers, correct? > Right. It leverages the existing update infrastructure for OCSP responses on stapling-supporting servers (or potentially in clients), and externalizes the cost of tracking the 'blessed' STH onto the CA, rather than to the millions of site operators. This keeps relative consistency with the original design of CT, which was to find the points in the Web PKI ecosystem most flexible to change (CAs) and deploying the robust fixes there. This certainly increases the friction to change - servers supporting robust OCSP stapling becomes a potential necessity - but it allows UAs to make those tradeoffs using the appropriate building blocks, based on their (or the site's) risk profile. This makes it even more of a preventative measure, at greater cost, but some UAs may feel that tradeoff is appropriate.
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
