Re: [Trans] Write-up of the "Strict CT" variant

[Andrew Ayer <[e-mail]>]

On Tue, 23 May 2017 09:26:00 -0400
Ryan Sleevi <[e-mail]> 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