On Tue, 23 May 2017 09:26:00 -0400 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 > - 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. I really like this idea. Note that RFC6962-bis needs one additional primitive to make this work: the get-sths endpoint. Otherwise there is no robust way to gather the blessed STHs for distribution to clients - one could always be missed if you are relying on calling get-sth repeatedly. This is why I think the get-sths endpoint is important. Regards, Andrew _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
