Subject: [dane] #39: Address interaction between EV certs and DANE

From: "dane issue tracker" <[email-masked]>
Date: Thu, 12 Apr 2012 12:32:17 -0000

#39: Address interaction between EV certs and DANE

 On 12. 4. 2012, at 10:26, Dave Cridland wrote:
 > > > As a final comment, I'd presonally like to see some comments about
 how, and when,
 > > > extended validation information should be checked and trusted. It
 seems to me that such
 > > > information should be ignored when handling type 2 or type 3
 certificates; or at best it
 > > > should be validated independantly using the traditional methods -
 that is, it should be
 > > > treated as a type 0 or type 1 certificate for the purposes of
 extended validation.

 On Thu Apr 12 12:03:37 2012, Ondřej Surý wrote:
 > > I think that Extended Validation is out of the scope of this document.
 And if I am not
 > > mistaken the CA which are able to issue EV certificates are hardcoded
 in the browsers.
 > > Thus I think that DANE-aware applications can use standard rules for
 EV certificates.

 On 12. 4. 2012, at 14:18, Dave Cridland wrote:
 > I think this needs calling out. EV seems like a very good argument for
 the existence of CAs in
 > a DANE world; I think it would be beneficial to touch on the subject if
 possible.

 So I am opening issue for EV certs. Does WG have any opinion how to
 address this?

-- 
---------------------------+----------------------------------------
 Reporter:  ondrej.sury@…  |      Owner:  draft-ietf-dane-protocol@…
     Type:  defect         |     Status:  new
 Priority:  minor          |  Milestone:
Component:  protocol       |    Version:
 Severity:  -              |   Keywords:
---------------------------+----------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/dane/trac/ticket/39>
dane <http://tools.ietf.org/dane/>

---

From: John Gilmore <[email-masked]>
Date: Thu, 12 Apr 2012 12:23:25 -0700

> So I am opening issue for EV certs. Does WG have any opinion how to address this?

Is there some RFC or standards-track Internet-Draft for EV certs?

Wikipedia suggests that it's an ad-hoc non-standard created by some CA
vendors and web browser makers.  It's apparently issued by the
"CA/Browser Forum", an unincorporated entity that doesn't even offer
an EV certificate on its own secure web site
(https://www.cabforum.org).  The Forum recently announced a Working
Group designed to reform itself into an org that offers wider
participation, "a more open and public process", etc.

If it's not an IETF standard, I suggest that we ignore it.  To the
IETF, a cert is a cert is a cert, and the RFCs on certs are careful
not to specify much about the exact contents of a cert, or how clients
should handle all the fiddly little bits attached to them.  DANE should
do the same.

	John

---

From: Tom Ritter <[email-masked]>
Date: Thu, 12 Apr 2012 16:42:48 -0400

> should handle all the fiddly little bits attached to them.  DANE should

There's also Organization-Validated certs which would have to be
handled specially too. I think browsers should not provide the O or EV
indicators to a self-signed cert that asserts itself as
Organization-Validated or EV.

I kind of think the standard should have some non-specific,
non-requirement security note saying a client should not afford high
security indicators (such as an EV indicator) to a self-signed
certificate - but I don't think any specific wording trying to cover
all the bases is appropriate.  I just worry someone implementing the
standard might forget about EV certs (as most of us did) which would
lead to a bug.  A security note would serve as a sufficient reminder.

-tom

---

From: Martin Rex <[email-masked]>
Date: Fri, 13 Apr 2012 03:00:52 +0200 (MEST)

> lead to a bug.  A security note would serve as a sufficient reminder.

I believe you're confusing things.

The three things (AFAIK) defined by the CABForum
Domain Validation (DV), Organization Validation (OV) and
Extended Validation (EV) for certificates are only relevant
to the color of some part of the browser UI chrome, but
they're entirely irrelevant to server endpoint identification
performed according to rfc2818 or rfc6125.

The only thing that rfc2818 and rfc6125 look at is the DNSName,
and that is present in all three kinds of certs.  Additionally
vetted attributes could provide additional clue to a human user
who actually looks at them and compares them to his intent,
but they're invisble to TLS clients implementing rfc2818 or rfc6125.

An approach of "DV+DANE" as minimum and OV or EV fine without DANE
would primarily hike the prices for TLS-enabling your server, an outcome
that I do not consider desirable.

-Martin

---

From: Tom Ritter <[email-masked]>
Date: Thu, 12 Apr 2012 21:23:42 -0400

> performed according to rfc2818 or rfc6125.

Correct.

> that I do not consider desirable.

The main reason I support DANE is so DV+DANE is not the minimum, and
we can eliminate the horrible chrome for self-signed certificate - so
we're on the same page there.

Here's what I'm trying to avoid:

- if ( certificateChainsToValidTrustAnchor() ) {
+ if ( certificateChainsToValidTrustAnchor() ||
certificateIsValidThroughDANE() ) {

  // 200 lines of random code

  if ( certificateIsEV() ) {
    showGreenBar();
    }
  else if ( certificateIsOV() ) {
    showOrganizationIndicator();
    }
  }

This patch makes a self-signed cert with the appropriate EV bits set
get the bright green browser UI.  I think a security note would remind
implementers to double check this case, just like we have security
notes for implementers in the TLS spec.

-tom

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 16 Apr 2012 12:05:11 -0400

CABForum was formed because the IETF PKIX list had previously declined
to become involved in defining Certification Policies and the ABA is
limited in scope to the US.

The PKIX WG did write an RFC on how to document a Certification policy
but actual policies themselves are out of scope.

As an unincorporated entity, the CABForum did not qualify for an EV
cert. It seems likely that the new forum will. In fact that might well
be one of the best reasons to decide on an incorporation route than
one of the other options. CABForum is not alone in being a standards
body with an 'interesting' incorporation status. Issuing certificates
to the IETF involved some interesting discussions.

Until recently, CABForum did not do protocol specification work
because there was no IPR policy in place and this is a pre-condition
for that type of work.

The aspect of CABForum work that is more likely to be relevant to DANE
is the BR requirements which are the base level requirements for any
issue of a CA SSL cert.

On Thu, Apr 12, 2012 at 3:23 PM, John Gilmore <[email-masked]> wrote:
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

-- 
Website: http://hallambaker.com/

---

From: "dane issue tracker" <[email-masked]>
Date: Mon, 30 Apr 2012 14:30:27 -0000

Changes (by warren@…):

 * status:  new => closed
 * resolution:   => wontfix

Comment:

 Having not seen any comments from the WG on how to address this, I'm
 closing it...

-- 
---------------------------+-----------------------------------------
 Reporter:  ondrej.sury@…  |       Owner:  draft-ietf-dane-protocol@…
     Type:  defect         |      Status:  closed
 Priority:  minor          |   Milestone:
Component:  protocol       |     Version:
 Severity:  -              |  Resolution:  wontfix
 Keywords:                 |
---------------------------+-----------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/dane/trac/ticket/39#comment:1>
dane <http://tools.ietf.org/dane/>