<br><br><div class="gmail_quote">On Wed Nov 19 2014 at 2:39:36 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 15:13, Ben Laurie wrote:<br>
><br>
><br>
> On Wed Nov 19 2014 at 8:53:57 AM 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>
>     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>><br>
>     > <mailto:<a href="mailto:sigbjorn@opera.com" target="_blank">sigbjorn@opera.com</a> <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<br>
>     no 'valid<br>
>     >     from' or 'valid to' fields, nor revocation pointers. Instead<br>
>     they carry<br>
>     >     a proof of the time they were issued, e.g. the latest hash<br>
>     from a CT<br>
>     >     log. The certificate is valid 3 days from that timestamp.<br>
>     Backdating is<br>
>     >     possible (and legal, but more than 3 days is pointless),<br>
>     pre-issuing is<br>
>     >     impossible. Clients have CT log data anyhow, and can compare<br>
>     their local<br>
>     >     time to the log time, and automatically account for any clock<br>
>     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<br>
>     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<br>
>     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>
><br>
> Surely this is not sufficient - the client also needs to check that the<br>
> cert is not expired, for which a time is needed (I think).<br>
<br>
If you know the issuance date[1], 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></blockquote><div><br></div><div>The question is: how do I know its 3 days later?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
[1] Technically this is a "issued no earlier than" date, but that should<br>
be good enough.<br>
<br>
--<br>
Sigbjørn Vik<br>
Opera Software<br>
</blockquote></div>