<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On 15 November 2013 06:02, James A. Donald <span dir="ltr"><<a href="mailto:jamesd@echeque.com" target="_blank">jamesd@echeque.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 2013-11-15 05:50, Tony Arcieri wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
And what of other solutions like CT or Tack?<br>
</blockquote>
<br></div>
With CT, when your browser hits a site, gets a certificate, it needs to check if the certificate is in a CT file, which is cryptographically secured to be the same for everyone.<br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
But, if you have check each newly encountered certificate in real time, why does it need the CA's signature?  (Other than to avoid threatening the CA business model.)<br></blockquote><div><br></div><div>This is not how CT works, the check is asynchronous: you get a signature from a log along with the certificate, and you later check that the log was honest. That is, trust but verify.</div>
<div><br></div><div>Synchronous checks would be nice, but the failure rate is too high. Even if it weren't, the extra latency is also a problem.</div><div><br></div><div>CT is a careful compromise that balanced deployability with effectiveness. Once it is in place, I'm sure we'll start working on compromises that move the needle towards even higher security at the cost of slower deployment.</div>
<div><br></div><div>For example, revocation is often cited as a problem. I agree. But to solve it without introducing other problems, we need to change servers. Changing _all_ servers takes around a decade.</div><div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The social mechanism underlying CT is:<br>
<br>
1. not everyone is allowed to write to the CT files.  It is a valuable privilege.<br>
<br>
2. the cryptographic properties of CT files make it easy to detect misbehavior.<br>
<br>
3. Denying someone the right to make further writes to the CT files is not disruptive, whereas trying to delete a CA is immensely disruptive, thus the threat to withdraw the privilege to write to CT files for misbehavior is far more credible than the threat to take a CA off the browser CA list.<br>

<br>
This being so, why should we care about CA signatures?  If a certificate is in the CT files, that is far more credible evidence of being a good certificate than if it is signed by a CA.  Let us allow all domain name registrars to write to the CT files, conditional, of course, on correct behavior.</blockquote>
<div><br></div><div>I think if you want this system, the appropriate vehicle is DNSSEC. A variant on CT for DNSSEC is clearly possible, and I hope my team can start working on that soon. We're a little busy right now, though.</div>
<div><br></div></div></div></div>