<br><br><div class="gmail_quote">On Wed Nov 19 2014 at 8:53:57 AM 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 18-Nov-14 18:22, Ben Laurie wrote:<br>
><br>
> On Mon Nov 10 2014 at 3:03:04 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>
>     So here is another suggestion:<br>
>     Create a special breed of short-lived certificates. They have no 'valid<br>
>     from' or 'valid to' fields, nor revocation pointers. Instead they carry<br>
>     a proof of the time they were issued, e.g. the latest hash from a CT<br>
>     log. The certificate is valid 3 days from that timestamp. Backdating is<br>
>     possible (and legal, but more than 3 days is pointless), pre-issuing is<br>
>     impossible. Clients have CT log data anyhow, and can compare their local<br>
>     time to the log time, and automatically account for any clock skew.<br>
>     Since clock skew is handled, expired certs can be treated just as<br>
>     harshly as revoked certs. Total data size on the wire should be smaller<br>
>     than the original proposal.<br>
><br>
><br>
> I would certainly be pushing for CT to be used for short-lived<br>
> certificates, just like any other, so that part I'm fine with.<br>
><br>
> However, if we're going to introduce logs as a trusted source of time,<br>
> then we would need to think about how logs can prove that their time is<br>
> honest. This strikes me as potentially quite tricky.<br>
<br>
Logs don't need a clock nor a timestamp. All the certificate needs to do<br>
is to include the latest hash published by the log, this proves that the<br>
certificate was issued after that hash was calculated. If that hash was<br>
delayed more than MMD after real time, the log would have had problems,<br>
this is all the proof we need. An issue for the client is to keep track<br>
of when hashes was published, but that has many solutions.<br></blockquote><div><br></div><div>Surely this is not sufficient - the client also needs to check that the cert is not expired, for which a time is needed (I think).</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
If you don't like using CT logs for proving that something was issued<br>
after-a-fact, then one can use any other public data which is unknown<br>
beforehand, examples below. Each can be scaled up to provide sufficient<br>
entropy, and all will need a list of approved sources. The point isn't<br>
to use any one of these, but to show that timestamps are a non-issue.<br>
* Temperature data at the time of issue.<br>
* The latest lottery numbers (there is surely a major lottery drawing<br>
happening in the world every few hours).<br>
* The latest sports results. (E.g. order of nation rankings in the<br>
latest multinational major event.)<br>
<br>
--<br>
Sigbjørn Vik<br>
Opera Software<br>
</blockquote></div>