[cabfpub] Pre-Ballot - Short-Life Certificates

[Ben Laurie]

On Wed Nov 19 2014 at 2:39:36 PM Sigbjørn Vik <sigbjorn at opera.com> wrote:

> 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.
>

The question is: how do I know its 3 days later?


>
> [1] Technically this is a "issued no earlier than" date, but that should
> be good enough.
>
> --
> Sigbjørn Vik
> Opera Software
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20141119/fbc21c36/attachment.html