<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Dec 18, 2013 at 4:08 PM, Eddy Nigg (StartCom Ltd.) <span dir="ltr"><<a href="mailto:eddy_nigg@startcom.org" target="_blank">eddy_nigg@startcom.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    <br>
    On 12/19/2013 01:29 AM, From Ryan Sleevi:
    <blockquote type="cite">
      <div dir="ltr"><br>
        <div class="gmail_extra"><div class="im">On Wed, Dec 18, 2013 at 3:23 PM, Eddy
          Nigg (StartCom Ltd.) <span dir="ltr"><<a href="mailto:eddy_nigg@startcom.org" target="_blank">eddy_nigg@startcom.org</a>></span>
          wrote:<br>
          </div><div class="im"><div class="gmail_quote">
            <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
              <div bgcolor="#FFFFFF" text="#000000"> But this is exactly
                how Diginotar was detected however - basically a few
                emails back I suggested that browser vendors nail the
                most important sites in their browser as "pins" and
                allow users to pin additional certificates to the
                respective sites. It's a very simple and efficient way
                to get some protection and allows detection for the most
                important sites.<br>
              </div>
            </blockquote>
            <div><br>
            </div>
            <div>So your idea is that every end-user is capable of
              evaluating the security policy of the site, without input
              of the site operator?</div>
          </div>
        </div></div>
      </div>
    </blockquote>
    <br>
    No, as not every user is capable or has the necessary
    interest/knowledge/integrity to monitor and review a log containing
    all issued certificates and to know what to do with this data. And I
    made the other arguments already at the managements list I think.</div></blockquote><div><br></div><div>This continued refrain demonstrates such a complete misrepresentation of the CT goals that I do not know how to further engage constructively or to explain how misguided this is.</div>
<div><br></div><div>It has been repeatedly explained to you, by multiple parties, that it is not the end users (that is, to use CA terms, "Relying Parties"), but instead the site operators, who will be monitoring the CT log.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
<div class="im"><br>
    <br>
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div>And who do these users yell at when pins break?</div>
          </div>
        </div>
      </div>
    </blockquote>
    <br></div>
    There is most likely a reason if that happens, this way or the
    other. A knowledgeable users will know the difference and the others
    will not pin any certificates to start with.</div></blockquote><div><br></div><div>So protection for nobody. Got it.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><div class="im"><br>
    <br>
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div>The suggesting that pinning is between user+browser,
              rather than site+browser, is certainly a far worse model,
              utterly incomprehensible and providing no value to end
              users.</div>
          </div>
        </div>
      </div>
    </blockquote>
    <br></div>
    I certainly works for me - it even worked for Google as far as I
    understood.</div></blockquote><div><br></div><div>As has been repeatedly explained, you don't understand.</div><div><br></div><div>At this point, I feel the only useful discussion or advice I can give you is to read the drafts, because your understanding is so far misplaced that it's impossible to engage in a constructive dialog without at least some effort on your part.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><div class="im">
<br>
    <br>
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div>Also, the idea that we should somehow balkanize the
              Internet, and only the "very important ones" get security,
              at the discretion of browsers, is a terrible one. </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br></div>
    It's where the attacks probably happen first with the most value.<div class="im"><br>
    <br>
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div>CT provides protection for every single user and site
              operator on the Internet - surely you can agree that has
              value?</div>
          </div>
        </div>
      </div>
    </blockquote>
    <br></div>
    That's a very worthy goal and I believe the vast majority get
    reasonable protection in any case already today. Otherwise we can
    stop using SSL if there is no value in the work CAs perform. Or
    change the rules, but don't basically double the work with another
    layer.<div class="im"><br>
    <br>
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div>Regardless of the views of pinning, however, the
              continued failures of the WebTrust and ETSI audit schemes
              to "prevent" mis-issuance has demonstrated to root store
              operators that it is no longer acceptable for continued
              trust in CA operations. </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br></div>
    Well, that's a very bleak interpretation - of course there were a
    bunch of failures (making me real angry too), but nothing is 100%
    ever. Not even CT will that be, trust me.<div class="im"><br>
    <br>
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div>By requiring audits be transparent - which CT does - it
              provides a much better trust signal to root stores and
              their users that the participating CAs are deserving of
              trust. </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br></div>
    I have no problem with some transparency - I'd be willing to hand
    over a list of all issued certificates to an agreed upon consortium
    (how about Google, Netcraft, EFF and Qualsys) for review if that
    would increase your trust of my work. However I'm not really
    interested to carry the costs your proposal implies (at least as far
    as I see it, with no real numbers yet) and our subscribers will be
    probably very upset because they'll have to pay for it in the end.<div class="im"><br>
    <br>
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div>A simple audit letter from an AICPA accountant or a
              qualified auditor is no longer sufficient, as the
              continued events demonstrate.</div>
          </div>
        </div>
      </div>
    </blockquote>
    <br></div>
    Can we skip auditing then if there is no value in that? Than
    everybody can become a CA as long as the certs are in the CT log? <br></div></blockquote><div><br></div><div>Like so many of your replies, I feel you have intentionally chosen to misinterpret my reply in order to further a goal that can only be seen as willfully obstructionist.</div>
<div><br></div><div>That something is no longer sufficient does not at all suggest that it is not necessary, nor that there is no value.</div><div><br></div><div>Eddy, I have tremendous respect for you and your efforts, but I feel at this time, we've reached an impasse at being able to fruitfully and productively discuss CT, its merits, and its risks. Without a good faith effort on your part to actually understand what is being proposed, both in terms of CT and pinning, and to explain your counter proposal, I feel there is nothing further of value to be added to the discussion here. </div>
<div><br></div><div>As has been previously discussed ( <a href="https://cabforum.org/pipermail/public/2013-September/002233.html">https://cabforum.org/pipermail/public/2013-September/002233.html</a> ), Google Chrome intends to require Certificate Transparency for all EV certificates issued after a future date. This is, as has been previously stated, an additional requirement that Google Chrome is imposing on certificates that it grants the EV badge to - in addition to, not in replacement of, the existing auditing requirements according to the CA/Browser Forum's EV Certificate Guidelines, and as documented at <a href="http://www.chromium.org/Home/chromium-security/root-ca-policy">http://www.chromium.org/Home/chromium-security/root-ca-policy</a></div>
<div><br></div><div>We appreciate your continued feedback in these plans, but at present, nothing has been shared that would cause us to re-evaluate these plans. CAs that are unable to meet these requirements will naturally find that certificates they issue will no longer appear as EV within Chrome, because Chrome cannot be assured that the certificates are truly worthy of the heightened trust communicated to end users. This may, and likely will, extend to all certificates at a future point, at which point CAs that are unable or unwilling to provide a publicly auditable log of their certificates will find these certificates marked as no longer trustworthy and operating in the public trust.</div>
<div><br></div><div>I do not say this to suggest we are inflexible, but merely to highlight the importance that CA's should make good faith efforts to understand what Certificate Transparency is and the problems it attempts to address and solve, in order that they might provide constructive feedback that can be used to inform and alter these plans, if necessary.</div>
<div><br></div><div>The point of CT is to provide a technical solution for what is and will be very much a program requirement for CAs that are treated as trusted by Chrome - namely, that all certificates be able to be audited, by any interested party, and at any time, in conforming to both the stated CP/CPS of the CA and to the program requirements of Chrome.</div>
<div><br></div><div>If there are alternative technical solutions that can meet that goal, we're happy to discuss them, but pinning - both the solution you've described and the solution that the rest of us have been using and implemented for the past several years - is not and will never be that, so it's not worth comparing.</div>
<div><br></div></div></div></div>