[cabfpub] Pre-Ballot - Short-Life Certificates

[Sigbjørn Vik]

On 18-Nov-14 18:22, Ben Laurie wrote:
> 
> On Mon Nov 10 2014 at 3:03:04 PM Sigbjørn Vik <sigbjorn at opera.com
> <mailto:sigbjorn at opera.com>> wrote:
> 
>     So here is another suggestion:
>     Create a special breed of short-lived certificates. They have no 'valid
>     from' or 'valid to' fields, nor revocation pointers. Instead they carry
>     a proof of the time they were issued, e.g. the latest hash from a CT
>     log. The certificate is valid 3 days from that timestamp. Backdating is
>     possible (and legal, but more than 3 days is pointless), pre-issuing is
>     impossible. Clients have CT log data anyhow, and can compare their local
>     time to the log time, and automatically account for any clock skew.
>     Since clock skew is handled, expired certs can be treated just as
>     harshly as revoked certs. Total data size on the wire should be smaller
>     than the original proposal.
> 
> 
> I would certainly be pushing for CT to be used for short-lived
> certificates, just like any other, so that part I'm fine with.
> 
> However, if we're going to introduce logs as a trusted source of time,
> then we would need to think about how logs can prove that their time is
> honest. This strikes me as potentially quite tricky.

Logs don't need a clock nor a timestamp. All the certificate needs to do
is to include the latest hash published by the log, this proves that the
certificate was issued after that hash was calculated. If that hash was
delayed more than MMD after real time, the log would have had problems,
this is all the proof we need. An issue for the client is to keep track
of when hashes was published, but that has many solutions.

If you don't like using CT logs for proving that something was issued
after-a-fact, then one can use any other public data which is unknown
beforehand, examples below. Each can be scaled up to provide sufficient
entropy, and all will need a list of approved sources. The point isn't
to use any one of these, but to show that timestamps are a non-issue.
* Temperature data at the time of issue.
* The latest lottery numbers (there is surely a major lottery drawing
happening in the world every few hours).
* The latest sports results. (E.g. order of nation rankings in the
latest multinational major event.)

-- 
Sigbjørn Vik
Opera Software