[cabfpub] Pre-Ballot - Short-Life Certificates

[Sigbjørn Vik]

On 19-Nov-14 15:13, Ben Laurie wrote:
> 
> 
> On Wed Nov 19 2014 at 8:53:57 AM Sigbjørn Vik <sigbjorn at opera.com
> <mailto:sigbjorn at opera.com>> wrote:
> 
>     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>
>     > <mailto: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.
> 
> Surely this is not sufficient - the client also needs to check that the
> cert is not expired, for which a time is needed (I think).

If you know the issuance date[1], and a rule that such certs expire
three days later, that is sufficient.

Clients recognize the hash from the log, look up when the certificate
was issued (when the hash was published), and set the certificate to
expire three days later.

[1] Technically this is a "issued no earlier than" date, but that should
be good enough.

-- 
Sigbjørn Vik
Opera Software