[cabfpub] Difference between CA issued DV and DANE certs

[Phillip]

There is in any case a big difference between what the EV guidelines require and what CAs actually do.

The EV criteria are the minimum. But CAs have always gone beyond the minimum. There are many controls that are much easier to employ in practice than define as a requirement.

It would take a really perverse CA to look to some loophole in their CPS as an excuse to keep some criminal gang operating. Most customers just don't pay enough for that to be worthwhile. And those that do buy bulk certs are hardly likely to be engaged in the type of fraud where a fake cert would help them. [Bernie Madoff etc. didn't use impersonation to steal billions]




On Oct 18, 2012, at 11:27 PM, Ryan Sleevi wrote:

> On Thu, Oct 18, 2012 at 7:46 PM, Jeremy Rowley
> <jeremy.rowley at digicert.com> wrote:
>> Hi Ryan,
>> 
>> I thought I'd reply to your points individually:
>> 
>> 1) Neither the Baseline nor EV documents define, for any concrete or
>> reliable sense, what "bad" is - particularly not to the claims you've
>> presented here or have been presented on the other thread
>> 
>> [JR] Incorrect. Section 13.1.5 of the baseline requirements lists a minimum
>> number of reasons that are considered "bad" things, including bad actions
>> and technical deficiencies.  As mentioned previously, most CAs will also
>> revoke if the certificate is used for purposes considered illegal in the
>> CA's jurisdiction of issuance and have documented this revocation practice
>> in its CPS.
>> 
>> 2) Neither the Baseline nor EV documents require, for any concrete or
>> reliable sense, what should be done in the case of "bad"
>> 
>> [JR] Incorrect.  The certificate should be revoked.  Again, see Section
>> 13.1.5.
>> 
>> 3) As has been pointed out thoroughly in a variety of forums, including most
>> notably the revocation working group, that in practice, revocation as
>> implemented today by Every Major Browser is not a security mechanism.
>> 
>> [JR] This is primarily a result of browsers refusing to use the information
>> provided, not the CAs providing the information. We've gone over the
>> arguments for and against using the information many times.  However, the
>> revocation working group is making strides towards remedying the browsers
>> concerns with the information and improving revocation from all viewpoints.
>> With the push of OCSP stapling, browsers should have a satisfactory  way of
>> obtaining information about revoked certificates.
>> 
>> As such, revocation provides little practical value against "bad", for some
>> value of "bad" that is not at all agreed upon by members, and which CAs are
>> not required to check for or respond to.
>> 
>> [JR] See above.  Also, pursuant to Section 13.1.2, all CAs must maintain a
>> certificate problem reporting system that can address (or at least
>> investigate) "bad" certificates within 24 hours of receipt. This contact
>> information is available to browser, subscribers, and relying parties.  CAs
>> are required to respond and check for bad certificates when they receive a
>> request through their certificate reporting system.  This means is practical
>> value against "bad", a clear definition of "bad", and a requirement that CAs
>> react to "bad"
> 
> Thanks for raising some excellent points, Jeremy.
> 
> For the sake of discussion, I was trying to use "bad" as an
> alternative to Phillip's "Internet crime", as I think Internet Crime
> directly suggests there are consistent laws on the Internet forbidding
> such behaviour. I think this sort of "bad", or if you will, "Internet
> crime", extends well beyond the cases covered in 13.1.5. So while we
> have a definition of "bad" provided in the BR, it's not the "bad" that
> was being discussed, which was sort of the point.
> 
> In the case of 13.1.5, and in the malware/crimeware situations that
> Phillip described as being a particular defense provided by CAs, the
> closest one comes to finding a common ground is in requirements 4
> ("The CA is made aware that a Subscriber has violated one or more of
> its material obligations under the Subscriber or Terms of Use
> Agreement") and 6 ("The CA is made aware that a Wildcard Certificate
> has been used to authenticate a fraudulently misleading subordinate
> FQDN"). It might be possible to consider 9 ("The CA determines that
> any of the information appearing in the Certificate is inaccurate or
> misleading") as well, but I would again suggest that's a function of
> the UDRP.
> 
> I would note that both of these are somewhat subjective terms, and are
> left on a CA-by-CA basis, without any good clarification as to what
> the minimum across all legal frameworks is (nor, incidentally, am I
> optimistic for such a baseline).
> 
> As both your and Phillip's responses have highlighted, the
> determination of illegal is presently left as subjective, both to the
> CA's interpretation and to the legal framework they're operating
> under, and thus not a consistently reliable measure for browsers to
> depend on. Because member CAs span a variety of legislations and legal
> frameworks, and in today's model with every CA being equal in terms of
> trust, the attacker need only go to the weakest, most-lax CA to obtain
> a certificate.
> 
> Likewise, because there is little guidance on what the material
> obligations are, I think we can agree that there are unquestionably a
> number of material differences in what CAs set for as the material
> obligations of subscribers, and that for any number of so-called
> "Internet crimes", it is likely that with a little shopping around, a
> Subscriber could easily find a CA whose policies are less than clear
> on such actions - or to start a CA that fully conformant with the BR,
> but in a legal jurisdiction without positions on such behaviours.
> 
> While I cannot speak to the day to day operations of CAs, from the
> policies that I have reviewed in the past, both in terms of EV and BR,
> I have little to no confidence that the the current Web PKI provides
> or mandates a sufficient or reliable defense against the "Internet
> crime" situations such that it becomes a strong, reliable benefit over
> the DANE model. Regardless of the work the CAs do, for the
> crimeware/malware model, browsers will continue to integrate solutions
> such as Safe Browsing and equivalent, and for the illegal/illicit
> activity, legal authorities will continue attacking the sources of
> these issues - including the DNS trust.
> 
> So while I don't balk at the notion that CAs are doing it - I think
> it's clear from this thread, there are active CAs in this area, which
> I think is a great defense in depth - I do have trouble believing that
> it is so uniform - and that it is audited as such - that it provides a
> compelling enough practical advantage over DANE.