[cabfpub] Pre-Ballot - Short-Life Certificates
benl at google.com
Wed Nov 19 14:04:36 MST 2014
On Wed Nov 19 2014 at 7:51:18 PM Sigbjørn Vik <sigbjorn at opera.com> wrote:
> On 19.11.2014 17:33, Ben Laurie wrote:
> > 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
> > 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?
> I am proposing certificates which can be proven not to be pre-issued.
> They could have issuance dates in them as well as the hash, I am just
> trying to save some bandwidth, to beat the original short-life proposal
> :) I just haven't managed to convince you that the issuance dates aren't
> actually needed yet.
> > 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?
> Short answer: The client needs to securely download a single recent
> hash/timestamp combination. Most likely this would be done from a vendor
> server. All vendors have a lot of servers that the clients routinely
> connect to anyway, and trust in the client implies trust in those
> servers. Most likely the client would download the entire list from a
> trusted server, but a single combination is all that is required.
This is no better than saying that the client securely downloads the
current time - which would not only solve the original problem, but a whole
bunch of others.
> Longer answer:
> What you are thinking of is how to bootstrap the dates. Note a few things:
> a) Logs can lie about timestamps of when certificates were logged
I don't think so - they log the timestamp alongside the certificate.
> b) Logs cannot lie about the order in which certificates were logged
c) The last entry in a log can be assumed to be the present time.
Logs are not required to log in time order.
> d) The motivation for logs/MiTM would be to make old hashes appear as
> new, so an old certificate could still be used. Making new hashes appear
> old would make the client block certificates.
> Without a single timestamp, a log could claim all certificates were
> logged within the last 5 minutes, and thus all valid. If the client
> knows a single hash/timestamp combination, it could counter this by
> offsetting log timestamps.
> Example: The client knows that cert A was logged 10 days ago, and the
> log claims it was issued 5 minutes ago. The client will then shift all
> timestamps from the log by 10 days, and all the certificates will have
Actually, the effect is that they are not yet valid (the time at which they
were issued has not yet been reached).
> Note that the known hash/timestamp must be recent (=3 days
> old), in this example the log could claim that all certs before and
> including cert A were logged 10 days ago, and all certs since were
> logged 5 minutes ago, and thus present 9 day old certs as valid.
This would require forking the log, and so would eventually be revealed by
But the problem is: suppose I (the attacker) don't care that all your other
More seriously: if I am the victim of such an attack (not a log fork, but a
rollback), how would I prove it?
> In the case where such secure downloads are needed to bootstrap a
> device, a successful block of that download would achieve the same as a
> revocation check block today. It would be up to the client how to deal
> with such cases.
> Sigbjørn Vik
> Opera Software
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Public