<br><br><div class="gmail_quote">On Mon, Sep 26, 2011 at 9:17 AM, Ralph Holz <span dir="ltr"><<a href="mailto:holz@net.in.tum.de">holz@net.in.tum.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi,<br>
<div class="im"><br>
> What the observatory measured was intermediate certificates with<br>
> different subject names. An intermediate certificate does not imply a CA<br>
> or even an RA capability.<br>
><br>
> Repeating a false claim does not make it true.<br>
<br>
</div>What does remain true is that the number of keys increases the attack<br>
surface if the keys are not under the same rigid control of one entity.<br></blockquote><div><br></div><div>In the case of the largest node in the EFF graph, the CA has 200 intermediate certs, each issued to a different educational institute.</div>
<div><br></div><div>I would be exceptionally surprised if those keys were in 200 separate HSMs.</div><div><br></div><div>Now the current situation is not acceptable. The CA in question has not responded to my enquires as to what their policy actually is. So it is entirely possible that they are doing it the stupid way. And this is not a situation that can be allowed to continue. </div>
<div><br></div><div>But what I take exception to is the jump from an observation that might imply the possibility of 200 CAs to a repeated assertion of fact. The EFF has not attempted to determine whether those 200 certs are independent CAs or merely 200 keys in a single HSM held by the CA. Yet EFF people are repeating the claim as fact and using it to drive a policy discussion.</div>
<div><br></div><div>That sort of thing makes me rather angry. It is a dishonest and a disreputable way to behave. And as I have pointed out to EFF board members, this is going to discredit the EFF.  </div><div><br></div><div>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
What is also true is that, e.g. Mozilla has no clue how many<br>
sub-ordinate CAs are out there as these are often considered trade<br>
secrets and not disclosed to the browser vendors. See the Mozilla lists<br>
for discussions on that topic. Mozilla might soon try and close that gap.<br></blockquote><div><br></div><div>Actually the industry is working to close that gap, not just Mozilla.</div><div><br></div><div>My firm belief is that we need to start by making all parties that perform public validation subject to the same audit requirement as a CA. </div>
<div><br></div><div>This will almost certainly eliminate public RAs as a class since it seems that the motivation for being an RA rather than a CA was due to the cost of the security policy and audit regime rather than the cost of building a SOC to do the signing.</div>
<div><br></div><div>When the RA class was introduced it was never the intention that they be allowed to perform public validation functions. The idea of an RA was that if a company like IBM wanted to buy 100 SSL certs or to issue S/MIME certs, it made most sense for the CA to validate '<a href="http://ibm.com">ibm.com</a>' and then for IBM to use its own internal processes to validate individual employees and departments / hosts etc within IBM.</div>
<div><br></div><div><br></div><div>So one change in terminology I have suggested is distinguish between a Validating RA (VRA) that performs the public validation function and a Local RA (LRA) that only performs additional validation and authorization checks within a scope that has been previously validated by the CA.</div>
<div><br></div><div>Incidentally, this is one of the reasons why I do not want to just start from scratch with a completely new PKI syntax and hierarchy. Thats like moving from UNIX to Windows NT back in 1994. When it was first introduced, WNT was expected to be the most secure O/S because it was built with security in mind from the ground up. At the time UNIX was the notoriously insecure O/S from the guys who invented the buffer overrun bug. </div>
<div><br></div><div>The practical consequences of social and policy issues often take some time to be found.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

While you are correct that an intermediate certificate does not imply a<br>
CA, I do tend to see a larger attack surface here, and would certainly<br>
not venture to say "all's good".<br></blockquote><div><br></div><div>The problem is that introducing an LRA began a way to reduce the attack surface. One of the reasons I take offense at the tabloid approach of the EFF polemic is that they are discouraging use of a valuable control by stigmatizing it.</div>
<div><br></div><div>Now in theory, PKIX policy constraints would provide a mechanism for locking down the capabilities of an LRA. Unfortunately very few people know how they are supposed to function, let alone how they are implemented in real world software. </div>
<div> </div></div><div><br></div>-- <br>Website: <a href="http://hallambaker.com/">http://hallambaker.com/</a><br><br>