<div>Yes, the world does have more things than browsers and I strongly suspect that most of the applications driving the bizarre demand for 512 bit certs will turn out to be that type of application. </div><div><br></div><div>
But the primary responsibility for choice of crypto algorithm and strength has always rested with the application developer. I have no control over whether an application uses IDEA or DES or AES. Why expect me to be responsible for your choice of public key strength?</div>
<div><br></div><div>Relying applications should reject cert chains with a key strength of less than 1024 bits and they should ideally have code in there to disable use of cert chains with a key strength of less than 2048 past some drop-dead date in the hopefully not to distant future and reject SHA-1 certs at some point as well.</div>
<div><br></div><div><br></div><div>I am quite happy to contribute to the industry effort to inform people on best practices. What I will not accept is your attempt to lay the blame for every fault you see in the use of crypto at my door. All that the CA does is to make statements about the holder of a private key corresponding to a public key. Relying parties can see for themselves that the public key is weak.</div>
<div><br></div><div>The reason that I do not want to take responsibility for this is that I can only control the certs that I issue. The only way to make the Internet safer is for application software to stop accepting use of bad cryptography. I want to see platforms stop supporting use of MD4, MD5 and all the rest of the obsolete junk crypto in their platforms. That is going to cause existing code to break so they are going to be very reluctant to do it.</div>
<div><br></div><div>I do not accept responsibility for changes that I don't have the power to enforce. If the industry wants to make me crypto algorithms Tzar and allow me to pick algorithms for them then I will. But I can't accept primary responsibility otherwise.</div>
<div><br></div><div>If we want to make constructive progress on this we need to have an industry discussion and make a decision as an industry to move forward. There are two forums where such a discussion could take place. One is IETF and the other is CA-Browser forum. </div>
<div><br></div><div><br></div><div>For all the faults you see in the SSL/CA system the fact is that it is the only application of public key cryptography that has been successful on the Internet. Actual use of S/MIME, PGP and IPSEC remains negligible.</div>
<div><br></div><div><br><div class="gmail_quote">On Wed, Nov 9, 2011 at 2:51 PM, Jacob Appelbaum <span dir="ltr"><<a href="mailto:jacob@appelbaum.net">jacob@appelbaum.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/09/2011 09:03 AM, Phillip Hallam-Baker wrote:<br>
> On Wed, Nov 9, 2011 at 11:40 AM, Daniel Kahn Gillmor<br>
> <<a href="mailto:dkg@fifthhorseman.net">dkg@fifthhorseman.net</a>>wrote:<br>
><br>
>><br>
>> Am i wrong in thinking that this makes the "please recount the number of<br>
>> CAs" concern seem like a distraction from deeper issues?<br>
>><br>
><br>
> No, not at all.<br>
><br>
> If you want this to be a productive and constructive effort to make the CA<br>
> system work better then there has to be trust on both sides.<br>
><br>
<br>
</div>That's pretty rich coming from Comodo!<br>
<div class="im"><br>
> If we have people misrepresenting results to make false claims then CAs<br>
> have to think twice before they respond to anything knowing that it may be<br>
> used for 'gotcha' purposes later on.<br>
><br>
<br>
</div>The count given by Peter and the EFF makes sense based on the<br>
explanations on this list.<br>
<br>
Please show us all that the data collected is either invalid or that you<br>
have a different dataset that somehow supersedes it.<br>
<div class="im"><br>
><br>
> Remember that currently there are no industry wide criteria for issue of DV<br>
> certs. We should have some very soon, but for fifteen years it was left to<br>
> individual CAs to make policy. Now the reason that Melih and I convened the<br>
> meeting that led to the formation of the CA-Browser forum was that we<br>
> recognized that there was a problem here that we both wanted to fix.<br>
><br>
<br>
</div>ssladmin@domain.tld is still pretty much the way that people issue DV<br>
certs. Hilariously bad - I should know, that's my default choice for a<br>
new email address these days.<br>
<div class="im"><br>
> There are many CAs that share the same goal of making the Internet trust<br>
> system more reliable and trustworthy. But don't present this as something<br>
> that is exclusively the fault of CAs. It is not (just) the fault of the<br>
> goalkeeper when the ball ends up in the back of the net.<br>
><br>
><br>
<br>
</div>When will Comodo come clean about the entire Comodogate scandal?<br>
<br>
This is almost entirely the fault of the CAs. What checks and balances<br>
have you built to prevent these kinds of compromises from happening in<br>
the first place?<br>
<div class="im"><br>
> I don't actually see any problem with .local domains using SSL. The real<br>
> problem comes from browsers telling end users that this means a site is<br>
> 'safe'. So one approach would be to tell browser providers that when SSL is<br>
> used at .local sites that the user should never see a padlock icon or any<br>
> other security indicator in primary chrome.<br>
<br>
</div>I guess you just answered my last question, eh?<br>
<br>
The world is more than browsers. This kind of thinking is why the fault<br>
for a great deal of security failures rests on the shoulders of the CAs.<br>
<br>
Sincerely,<br>
Jacob<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>Website: <a href="http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>