[cabfpub] Pre-Ballot - Short-Life Certificates

[Sigbjørn Vik]

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

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.

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

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