<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 19, 2019 at 10:33 AM Shumon Huque <<a href="mailto:shuque@gmail.com">shuque@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Wed, Jun 19, 2019 at 9:01 AM Phillip Hallam-Baker <<a href="mailto:phill@hallambaker.com" target="_blank">phill@hallambaker.com</a>> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> And BTW: If we count trust roots the way that the EFF did, DNSSEC has a<br>
> million trust roots (or however many zones are signed) not one. It was an<br>
> utterly bogus comparison.<br>
<br>
This is in turn a false analogy.<br></blockquote><div><br></div><div><div style="font-size:small">No, the analogy is exact, The DFN root also constrained the sub-CAs so that they could not issue an arbitrary certificate. This was pointed out to the EFF, they chose not to correct.</div></div></div></div></blockquote><div><br></div><div>Hi Phil,</div><div><br></div><div>Can you provide a pointer to this EFF study?</div></div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">It is cited in the paper you list, it was from 2010 though.</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>The study that most people cite is this one by the University of Michigan from IMC, 2013:</div><div><br></div><div>    <a href="https://conferences.sigcomm.org/imc/2013/papers/imc257-durumericAemb.pdf" target="_blank">https://conferences.sigcomm.org/imc/2013/papers/imc257-durumericAemb.pdf</a><br></div><div><br></div><div>Admittedly, it's a bit dated, and I'm sure CT etc have improved things some, but this paper does not paint a pretty picture. </div></div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">The use of name constraints was not practical until relatively recently due to the legacy browser issue. But CABForum was already established at that point and the authors could have approached people and found out why the operational decisions were made as they were. But they had the story they wanted to tell.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The fact is that (with some exceptions that had already been stamped out by that time) even without name constraints, commercial CAs did not issue unconstrained subordinate CA certs for signing keys not covered by a full CPS. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">"However with only 20% of the organizations controlling signing
certificates being commercial certificate authorities and less than
25% of commercial authorities participating in the workgroup, there
remains a disconnect."</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Bullshit, there is no such thing as controlling a signing certificate, the only thing that can be controlled is the signing key. At the time the paper was written, at least 95% of the signing keys were held by commercial CAs. And of the 75% of commercial CAs that don't participate in CABrowser forum, most are not actually operating at all being CAs that are either in startup mode or were started and not progressed.</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>They find ~ 1800 distinct CAs including root CAs and sub-CAs issued to organizations, controlled by 683 distinct organizations. Only a tiny minority of the sub-CAs actually had a Name Constraints extension, so most of them were in effect unconstrained in their ability to issue. (Let's disregard for the time being that the observed Name Constraints were not marked 'Critical', so were in effect optional for relying party software).</div></div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">They were constrained by the private key being held by the root CA.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">No university that was part of the DFN network had the ability to sign certificates for anyone. The private key for every sub-CA was held by DFN. Which they confirmed after the original EFF study but the EFF chose not to make a correction despite knowing that their claim of 1800 sub-CA signers was incorrect by at least 650.</div></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>Have the findings in that paper been challenged or debunked? If so, I haven't seen it. It would be good to re-run this study for 2019.</div></div></div></blockquote><div><br></div><div class="gmail_default" style="font-size:small">It would be interesting to see how the numbers have changed now that CABForum has new requirements on Sub-CAs and that browsers have to accept ECC certs. making proper processing of path constraints viable.</div></div></div>