<br><br><div class="gmail_quote">On Fri, Oct 12, 2012 at 2:56 PM, Rick Andrews <span dir="ltr"><<a href="mailto:Rick_Andrews@symantec.com" target="_blank">Rick_Andrews@symantec.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Ryan,<u></u><u></u></span></p><p class="MsoNormal">
<span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Thanks for your speedy review. You raise a good point about DANE, one which the entire Forum may want to debate. IMO, we (at least the CAs) should be united in discouraging the use of DANE options that disable PKIX chain validation. If browsers add DANE support for option 3 (no PKIX chain validation), then a phisher could set up a fake site with a self-signed cert, and users visiting it would receive no warning whatsoever. I believe there’s value if having a CA vet the certificate holder, so the user can’t be directed to <a href="http://bunkofamerica.com" target="_blank">bunkofamerica.com</a> and get fooled into thinking it’s their bank.</span></p>
</div></div></blockquote><div><br></div><div>At the risk of sparking the debate (and perhaps we should start a separate thread for that), I would simply point out that under the current Baseline Requirements, this is no different than the security assurances afforded by Domain Validated certificates.</div>
<div><br></div><div>The only difference here is that with DV, the CA is checking the presence of some record or information from some registrar (WHOIS records) on behalf of the registrant, whereas in the DANE case, the relying party is checking the presence of some record or information from some registrar (DS keys) about the server.</div>
<div><br></div><div>I'm aware that the language of  BR 1.0, Section 11.5 is meant to prevent this, but as written, there's very little guidance as to what constitutes a high risk request, nor is there some industry-shared database of such high-risk requests (to the best of my knowledge), and as such, as relying parties, there is no guarantee as to what vetting has been done by the issuing CA regarding such requests.</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"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Having said that, though, I suspect DANE will involve much debate and I’d rather not wait to resolve that. If others agree with you, I’ll roll back the language to make it less contentious.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">What are Google’s plans for DANE support in Chrome? I suppose it will be dependent on platform support, since Chrome relies on the OS for crypto and PKI.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">-Rick</span></p>
</div></div></blockquote><div><br></div><div>While I cannot speak about any plans for DANE, I do want to clarify one point here. Chromium and Chrome currently rely on the OS for trust anchor management (mod EV certificates and policies, which we manage locally).</div>
<div><br></div><div>We also attempt to make use of the OS-provided PKI path building and validation routines, but only when appropriate and they offer suitable functionality. However, we're (I'm) currently in the process of migrating code away from using OS PKI path building and validation on some platforms, due to relying on deprecated-but-not-replaced APIs or otherwise non-5280 implementations.</div>
<div><br></div><div>However, for general purpose crypto (and for potential future uses, such as the W3C Web Crypto API), Chromium ships its own crypto implementation - or more accurately, shares the same underlying crypto implementation with Firefox, which is NSS.</div>
<div><br></div><div>So the clarification is more "Chrome relies on locally-configured trust settings (System & Enterprise)", and the rest is all in flux and dependent upon platform - and even the trust anchor management is not a hard guarantee :)</div>
</div>