<br><br><div class="gmail_quote">On Thu, Nov 10, 2011 at 12:36 PM, Daniel Kahn Gillmor <span dir="ltr"><<a href="mailto:dkg@fifthhorseman.net">dkg@fifthhorseman.net</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 11/10/2011 12:14 PM, Phillip Hallam-Baker wrote:<br>
> But the primary responsibility for choice of crypto algorithm and strength<br>
> has always rested with the application developer. I have no control over<br>
> whether an application uses IDEA or DES or AES. Why expect me to<br>
> be responsible for your choice of public key strength?<br>
<br>
</div>To be clear: are you saying that CAs should be willing to issue<br>
certificates over EE public keys that are arbitrarily short?<br></blockquote><div><br></div><div>No, I am saying that the decision to ban short keys needs to be </div><div>the responsibility of the whole industry and not just something </div>
<div>to be left to CA policy because it is only going to stick as</div><div>an industry wide commitment.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

What about issuing certificates over public keys that are known to be<br>
compromised (e.g. public keys corresponding to the etch bad-key blacklist)?<br></blockquote><div><br></div><div>Again, more than happy to put in additional controls to catch</div><div>known problems. But that is not the same as accepting </div>
<div>responsibility.</div><div><br></div><div>Let us imagine for the sake of argument that there was a weak key </div><div>issue that was not completely trivial. Say the work factor of the key </div><div>was 2^64 so that the key is definitely unsafe but checking it is</div>
<div>going to be very expensive. And let us say that the CSRs are </div><div>indistiguishable from CRSs from other software and it is going to </div><div>require spending $50 worth of CPU to check out 100,000 keys.</div><div>
<br></div><div>Now if someone was to make that kind of mistake I would </div><div>expect that the CAs would be anxious to make sure that</div><div>our customers are secure but that does not mean accepting </div><div>responsibility for fixing the problem and paying the $5 million </div>
<div>for the necessary CPU time. That is very clearly the application</div><div>provider responsibility.</div><div><br></div><div> </div><div>Now what would happen if the application provider refused to </div><div>pay up would be another issue. But even if the CAs end up</div>
<div>accepting the cost of cleanup they are not accepting </div><div>responsibility.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
What responsibility do you think a reasonable CA has to its subscribers<br>
if it becomes aware that their secret key material may be compromised?<br>
<br>
What responsibility do you think a reasonable CA has to its relying<br>
parties if it becomes aware that a secret key which they have certified<br>
may be compromised?</blockquote><div><br></div><div>See above. The primary responsibility for making sure the crypto is</div><div>strong enough has to fall on the application provider.</div><div><br></div><div>The CAs should provide a backup but this does not absolve the </div>
<div>application designer from making the right choice.</div><div><br></div><div><br></div><div>What I am objecting to here is that this exercise seems to only</div><div>ever be interested in holding CAs accountable.</div>
<div><br></div></div><div><br></div>-- <br>Website: <a href="http://hallambaker.com/">http://hallambaker.com/</a><br><br>