[cabfpub] Revised document for Ballot 89 - Adopt Requirements for the Processing of EV SSL Certificates v.2

[Ryan Sleevi]

On Fri, Oct 12, 2012 at 2:56 PM, Rick Andrews <Rick_Andrews at symantec.com>wrote:

> Ryan,****
>
> ** **
>
> 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 bunkofamerica.com and get fooled into thinking it’s their
> bank.
>

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.

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.

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.


****
>
> ** **
>
> 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.****
>
> ** **
>
> 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.****
>
> ** **
>
> -Rick
>

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).

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.

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.

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 :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://cabforum.org/pipermail/public/attachments/20121012/efb64615/attachment.html