[cabfpub] Pre-Ballot - Short-Life Certificates
sigbjorn at opera.com
Wed Nov 19 12:51:12 MST 2014
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.
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.
More information about the Public