Subject: Re: [dane] cert authority authz (was: Starting WGLC on: draft-ietf-dane-use-cases-02)

From: =JeffH <[email-masked]>
Date: Fri, 13 May 2011 13:41:57 -0700

PaulH replied..
 >
 > On May 13, 2011, at 9:53 AM, =JeffH wrote:
 >
 >> Yoav Nir <[email-masked]> suggested..
 >>>
 >>> In section 3.1 we might add what PHB suggested in his CAA proposal -
 >>> that CAs check the DNS before signing certificates, so if the DNS says
 >>> that Alice's certificate must be signed by "ComSign Secured CA", Charlie
 >>> won't sign it.
 >>
 >> It seems to me that the DANE charter scope does not extend to this
 >> requirement. I could be wrong, but that's how it reads to me.
 >>
 >> Also, Phill's application for issuance of the CAA RRTYPE was approved last
 >> month..
 >>
 >> http://www.ietf.org/mail-archive/web/dnsext/current/msg11181.html
 >>
 >> ..and so wrt this cert authority authz functionality, those who have
 >> feedback/thought on it, ought to comment in the context of
 >> draft-hallambaker-donotissue on the [email-masked] list.
 >
 >
 > I do not see anything in the charter that prevents this from being a use
 > case for DANE. The *ability* for CAs to check the DNS and base a
 > certificate-issuance decision on that is not in or out of scope, and it
 > seems like it is a use case that can be met with DANE.

Agree that it seems that the cert authority authz use case could be met with DANE.

Of course, actually deciding whether it's within or without DANE scope is for 
the wg chairs and the AD(s) to figure out (yes?)

I was more or less trying to give a heads up as well as maintain focus. Whether 
the CA-pre-cert-issuance-check (to coin a name) use case is in or out of the 
use case doc isn't a huge matter to me.

I thought it might be out of scope due to at least this statement in the 
present charter..

   Initial deliverables for this working group are limited to distribution
   of bindings between names within the zone operator's control and public
   keys.  More general statements of policy for a domain are out of scope,
   and new tasks in this area may only be adopted through a re-chartering.

However if the WG and chairs desire to add this use case to the doc, that's fine.

Of course, one would have to then write a spec similar to 
draft-hallambaker-donotissue specifying how to accomplish the 
CA-pre-cert-issuance-check using DANE DNS records. And then there's the 
two-specs-solving-same-problem thing to either sort out or let dangle.

=JeffH

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 13 May 2011 13:55:04 -0700

I'm going to push back a bit, not because I'm hyping one view, but because I hope folks have clarity about what the document in question is doing.

On May 13, 2011, at 1:41 PM, =JeffH wrote:

> Of course, actually deciding whether it's within or without DANE scope is for the wg chairs and the AD(s) to figure out (yes?)

Yes, the latter.

> I was more or less trying to give a heads up as well as maintain focus. Whether the CA-pre-cert-issuance-check (to coin a name) use case is in or out of the use case doc isn't a huge matter to me.

Good name.

> I thought it might be out of scope due to at least this statement in the present charter..
> 

I believe that a *use case* that says "Charlie has agreed to check the DNS before issuing certificates and would like a way to do that" meets that paragraph of the charter. If Alice can distribute "bindings between names within the zone operator's control and public keys" in such a way that Charlie has something to check in the DNS as part of a CA-pre-cert-issuance-check, then the first sentence is met. As long as the use case is not "Alice demands that every CA in the world do what she says in her DANE record" or "Alice's policy is that her domain must only be signed by Charlie", I think the second sentence is covered as well.

> Of course, one would have to then write a spec similar to draft-hallambaker-donotissue specifying how to accomplish the CA-pre-cert-issuance-check using DANE DNS records. And then there's the two-specs-solving-same-problem thing to either sort out or let dangle.

I disagree. Saying "If Charlie wants to do X, here is a way to fulfill that desire" is quite different than "If Charlie wants to do X, here is the only acceptable method." I'm not saying we will actually be able to meet the use case in the protocol document; I just don't see that it is impossible so therefore we shouldn't even think of listing the use case.

--Paul Hoffman