[cabfpub] Difference between CA issued DV and DANE certs

[Ryan Sleevi]

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.