<br><br><div class="gmail_quote">On Wed Nov 19 2014 at 4:00:10 PM Sigbjørn Vik <<a href="mailto:sigbjorn@opera.com">sigbjorn@opera.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 19-Nov-14 16:35, Ben Laurie wrote:<br>
><br>
><br>
> On Wed Nov 19 2014 at 2:39:36 PM Sigbjørn Vik <<a href="mailto:sigbjorn@opera.com" target="_blank">sigbjorn@opera.com</a><br>
> <mailto:<a href="mailto:sigbjorn@opera.com" target="_blank">sigbjorn@opera.com</a>>> wrote:<br>
><br>
>     If you know the issuance date, and a rule that such certs expire<br>
>     three days later, that is sufficient.<br>
><br>
>     Clients recognize the hash from the log, look up when the certificate<br>
>     was issued (when the hash was published), and set the certificate to<br>
>     expire three days later.<br>
><br>
><br>
> The question is: how do I know its 3 days later?<br>
<br>
I am not certain I understand the question, attempting to answer all the<br>
variants I can think of:<br>
<br>
Q: How do you know that certain certificates have a 3 day expiry time?<br>
A: We define them that way, and might even have some marker in them,<br>
stating that this is a certificate of a certain type.<br>
<br>
Q: How do you know that it is three days later than some timestamp?<br>
A: You check the current date and compare to the timestamp.<br>
<br>
Q: How do you know the date to calculate the expiry time from?<br>
A: You check the date when the hash was published.<br>
<br>
Q: How do you know the date when the hash was published?<br>
A: The client (or a vendor operated server) regularly fetches hashes,<br>
and stores when they were published.<br>
<br>
Q: What if the client clock is off?<br>
A: If the client thinks it is 1st of March, it downloads a hash, and<br>
stores its publication date as the 1st of March. Two days later, that<br>
hash is encountered in a certificate. The client thinks it is the 3rd of<br>
March, and thinks the certificate is valid till the 4th of March, so the<br>
certificate is allowed. What date it actually is is not relevant.<br></blockquote><div><br></div><div>This is the one I meant ... so:</div><div><br></div><div>a) I'm not really sure I understand the protocol you are proposing here, perhaps you could be a little more detailed?</div><div><br></div><div>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?</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Q: How do you know the real date, or the difference between the local<br>
date and the real date?<br>
A: You don't. You do need that for regular certificates, but not for<br>
this suggestion.<br>
<br>
--<br>
Sigbjørn Vik<br>
Opera Software<br>
</blockquote></div>