[cabfpub] Pre-Ballot - Short-Life Certificates

Ben Laurie benl at google.com
Wed Nov 19 16:33:24 UTC 2014


On Wed Nov 19 2014 at 4:00:10 PM Sigbjørn Vik <sigbjorn at opera.com> wrote:

> On 19-Nov-14 16:35, Ben Laurie wrote:
> >
> >
> > On Wed Nov 19 2014 at 2:39:36 PM Sigbjørn Vik <sigbjorn at opera.com
> > <mailto:sigbjorn at opera.com>> wrote:
> >
> >     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?
>
> I am not certain I understand the question, attempting to answer all the
> variants I can think of:
>
> Q: How do you know that certain certificates have a 3 day expiry time?
> A: We define them that way, and might even have some marker in them,
> stating that this is a certificate of a certain type.
>
> Q: How do you know that it is three days later than some timestamp?
> A: You check the current date and compare to the timestamp.
>
> Q: How do you know the date to calculate the expiry time from?
> A: You check the date when the hash was published.
>
> Q: How do you know the date when the hash was published?
> A: The client (or a vendor operated server) regularly fetches hashes,
> and stores when they were published.
>
> Q: What if the client clock is off?
> A: If the client thinks it is 1st of March, it downloads a hash, and
> stores its publication date as the 1st of March. Two days later, that
> hash is encountered in a certificate. The client thinks it is the 3rd of
> March, and thinks the certificate is valid till the 4th of March, so the
> certificate is allowed. What date it actually is is not relevant.
>

This is the one I meant ... so:

a) I'm not really sure I understand the protocol you are proposing here,
perhaps you could be a little more detailed?

b) It seems to rely on the client having some consistent offset from the
correct date ... to focus the difficultly a little more closely, let's
consider the case of a device that has just booted, has no memory from
previous runs, and sees a certificate of this new type: how does it
determine that the cert is currently valid?


>
> Q: How do you know the real date, or the difference between the local
> date and the real date?
> A: You don't. You do need that for regular certificates, but not for
> this suggestion.
>
> --
> Sigbjørn Vik
> Opera Software
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20141119/37894ef4/attachment-0003.html>


More information about the Public mailing list