[cabfpub] Pre-Ballot - Short-Life Certificates

[Ben Laurie]

On Wed Nov 19 2014 at 8:53:57 AM Sigbjørn Vik <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>> 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 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20141119/346dfa56/attachment.html