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

[Eran Messeri <[e-mail]>]

Below is a write up of the “Strict CT” variant, based on Mozilla’s
suggestion.
The goal of this write-up is to serve as a foundation for a document that
will describe the deployment of CT needed to operate with stronger
guarantees for TLS clients, as well as the protocol extensions necessary to
deploy it.

*Goal*: Provide TLS clients with proof of inclusion to a tree state they
already know (save clients the need to audit logs themselves).

*Overview*:

   - UA vendor ("auditor") periodically collects an STH (denoted "official"
   STH [1]) from each log, distributes it to its UAs ("clients"). Clients are
   expected to cache all STHs.
   - CA/Site Owner ("submitter") submits (pre)certificate to the log, gets
   SCT [2].
   - Submitter waits until the next official STH that includes the
   certificate, gets an inclusion proof to be served alongside the certificate
    + SCT.
   - In the TLS handshake, clients get certificate + SCT + inclusion proof
   to an official STH they know about [5].


The purpose of the UA vendor sending down the official STH is to provide
third-party verification of the consensus.
The purpose of the submitter bundling the STH + inclusion proof is to avoid
the client having to retrieve it via some other protocol


Options for dealing with the delayed usability of certificates:

   - Submitter waits until an inclusion proof to an “official” STH becomes
   available, only starts serving that certificate then (could take up to 2 x
   MMD - two days, typically).
      - The CA could wait until the proof becomes available and only issue
      the final certificate then - delay issuance by up to MMD.
      - The requester could get the certificate immediately but only start
      using it once it’s able to obtain an inclusion proof to an
official STH [3].
   - Certificate is used immediately, only with SCT: Clients accept
   certificates only with SCTs for a limited duration; after that an inclusion
   proof must be accompanied [4].
   - Opt-in: servers requires presence of proofs via header / X.509
   extension [6].
   - Certificate is used after the client can fetch an inclusion proof and
   an STH the log has produced; if it’s an unknown STH the client sends it to
   the auditor for reconciliation.


Footnotes:

[1] The "official" STH does not have to be explicitly marked: Assuming
daily STH push cycle, a log could mint one marked STH every day, to be
distributed to clients. Alternatively, if STH issuance frequency (which
6962-bis requires specifying) is not too high (e.g. hourly) then the
"official" STH could be the first one issued after midnight UTC
(synchronizing on the clock).

[2] An intermediate improvement is to return, rather than just SCT, the SCT
+ STH issued immediately afterwards (~seconds) + inclusion proof to that
STH. Effectively, this would rid of SCTs - the STHs issued that way will
have the same privacy properties of SCTs, but it will simplify the system
by removing the requirement to deal with inclusion proofs, only consistency
proofs  (clients would still have to know how to check an inclusion proof
to those intermediate STHs, but not have to  fetch them).
If this variant can be successfully deployed using 6962-bis, in
6962-bis-bis we could get rid of SCTs completely.

[3] The web server only has to do this once for each new certificate since
clients are expected to cache all STHs indefinitely.

[4] That requires auditing logs asynchronously, since an attacker with
persistent access could keep getting new SCTs issued, or some clients may
not have fresh STHs because they missed some updates.

[5] There will be a time period where a submitter serves an official STH
that the client doesn’t yet know about because it wasn’t distributed, or
received, yet. Clients could send these for reconciliation, or the
submitter required to not serve it yet until it was distributed to clients.

[6] In theory, a new certificate, with the inclusion proof embedded, could
be issued - but it may run afoul of the restriction on issuing different
certificates with the same serial number.

Eran