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

[Ryan Sleevi <[e-mail]>]

On Tue, May 23, 2017 at 9:49 AM, Eran Messeri <[e-mail]> wrote:

>
>
> On Tue, May 23, 2017 at 2:26 PM, 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
>>
> 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.