[cabfpub] Pre-Ballot - Short-Life Certificates
benl at google.com
Wed Nov 19 08:35:02 MST 2014
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
> > > 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
> > > 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
> > certificate was issued after that hash was calculated. If that hash
> > delayed more than MMD after real time, the log would have had
> > this is all the proof we need. An issue for the client is to keep
> > 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, 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?
>  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...
More information about the Public