[cabfpub] Difference between CA issued DV and DANE certs

[Jeremy Rowley]

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"

As such, as much as you point out that we can not expect ICANN to actively
police the DNS information, from the perspective of a browser/root store and
of what the BR and EV documents provide, I feel that we can not expect the
CAs to actively police the certificate information.

[JR]  I strongly disagree. I believe the point of having a root program is
to ensure that CAs are following procedures to police their issuance of
certificates and ensure that CAs are following minimum practices and
guidelines.  

The security of the overall CA system is continually limited by the weakest
link, which is perhaps why browser and root store operators feel so inspired
as to participate in this Forum and to work to find consensus in ensuring
that the level of security maintains parity (and ideally, continually
rises), rather than sinking to the lowest common denominator. As such,
unless and until every CA is performing the same minimal set of checks, then
the business practices of individual CAs, however right and noble and good,
regrettably provides little assurances to the overall trust in the Web PKI
when compared to an alternative system, such as DANE.

[JR] This is a recognized problem and one which I think the revocation group
will find a good solution.  Proposals such as CT and CAA both go a long way
towards limiting the weakest link dilemma.  Additional proposals will likely
be forwarded to the group shortly.

Again, I want to be clear I'm not a DANE apologist. I think it brings its
own issues to trust, and that it fails to solve several of the existing
issues that exist with the PKI we have today. These are things that work
such as CAA, HSTS, PKP and CT are on their way to addressing. As I mentioned
in my previous mail, it *may* be that the security indicators for
DANE-acquired information (which only assert bindings of domain names to
keys) should be different than the security indicators for PKIX-acquired
information (which asserts, depending on assurance levels, either the
bindings of domain names to keys or the bindings of organizational
information to keys). But I'm not sure that I can agree at all the
suggestion to show no indicator, or that the lock is a sacred indicator.

[JR] I don't disagree that the pkix and DANE are different.  I don't think
the lock indicator is sacred, but I agree with Phillip that it means more
(or at least should mean more) than a secure connection.  At DigiCert, we
believes it means the communication is with a verified entity.

4) Based on our understanding of actual Internet users, users are not
conditioned to associate the lock/"secure" branding with the claims of the
CAs regarding bindings of identities/key holders to certificate, but rather
and simply, the binding of domain name to key.

[JR] We'd love to remedy that understanding. We have standards for the
validation of information in a certificates.  I'd love to see a browser
start displaying the information validated or at least provide this
information in a useful manner.  The current browser implementation on how
to find verified information is very unwieldy, requiring too much specific
knowledge and a long series of clicks. 

I can appreciate the work done with EV to attempt to condition users to a
different set of expectations, but I have serious reservations that many end
users have actually read the issuing CA's CP or CPS and understood the
liability or assurance statements with respect to the information presented
therein.

[JR] That may be true.  However, both the baseline requirements and EV
Guidelines contain requirements for liability and assurance. This means all
CAs are held to at least the same minimum level of performance and the same
minimum level of liability for failing to meet those standards.  The EV
Guidelines have gone a long way to improving end user expectation.  The
minimum guidelines are brand new.  I imagine once they've aged as well as
the EV Guidelines, you'll see an even higher level of satisfaction. 

Jeremy