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 09:53:14 -0700

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.

=JeffH

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 13 May 2011 10:43:54 -0700

On May 13, 2011, at 9:53 AM, =JeffH wrote:

> 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.
> 
> ..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.

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Fri, 13 May 2011 18:28:25 -0400 (EDT)

> 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 s…

I agree. Having one record for applications and one record for CAs seem strange.

If it does become a dane use case, then like I suggested for the CAA record, there should
be a valid "null record" to state that no CA should issue/be trusted. This would be to
avoid people using "bogus" data to accomplish the same.

So yes, it would be a good use case to add DANE.

Paul

---

From: Yoav Nir <[email-masked]>
Date: Sat, 14 May 2011 09:11:05 +0300

> avoid people using "bogus" data to accomplish the same.

If we're using the same record for CAs and applications, what would the null record mean for applications?

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 16 May 2011 09:52:00 -0400

> If we're using the same record for CAs and applications, what would the null record mean for applications?

I think the better solution would be to just make up a cert/CA and lock to that cert/CA, preventing any other cert/CA from validating.  There's not a need for a null record, just positive record pointing to something else.

--Richard

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 16 May 2011 12:43:11 -0400

Actually, this was one of the two use cases for which the policy OID
mechanism was originally proposed. 'Never issue' and 'only issue EV' being
two cases we could not support using the path directive.

I would prefer to have this be an OID specified on the IETF or CABForum OID
arc. That is what they are for. Since the EV oid has to be CABForum, they
might as well do the null OID.

Alternatively, I could just add a 'null' directive and make it simpler
still:

example.com  CAA 1 null

The question there would become, why would you want to use such a directive?
Wouldn't not wanting a certificate be a consequence of not wanting the
domain to be used in any context whatsoever? So maybe there should be some
use of flags to say 'don't issue, don't rely, don't contact any service at'

On Mon, May 16, 2011 at 9:52 AM, Richard L. Barnes <[email-masked]> wrote:

> I think the better solution would be to just make up a cert/CA and lock to
> that cert/CA, preventing any other cert/CA from validating.  There's not a
> need for a null record, just positive record pointing to something else.
>
> --Richard
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
>

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

---

From: Paul Wouters <[email-masked]>
Date: Mon, 16 May 2011 15:47:01 -0400 (EDT)

On Mon, 16 May 2011, Phillip Hallam-Baker wrote:

> Alternatively, I could just add a 'null' directive and make it simpler still:
> 
> example.com  CAA 1 null
> 

If someone is using DANE with a non-cert entity (raw key) and does not want legacy
clients to be fooled into using a CA for which they have a trust anchor loaded on
the client.

Though dane currently has no such format, work is (slowly) progressing to add it.

Paul

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 16 May 2011 18:25:33 -0400

No, for that use case you would be publishing your own root.

The possible use cases for null would be either for a domain that wants to
accept connects but does not want to ever use security or for a domain that
is parked without any intention of being used at all.

Is the first use case one that would be desirable to support at all?

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 16 May 2011 20:01:22 -0700

On May 16, 2011, at 9:43 AM, Phillip Hallam-Baker wrote:

> Actually, this was one of the two use cases for which the policy OID mechanism was originally proposed. 'Never issue' and 'only issue EV' being two cases we could not support using the path directive.
> 
> I would prefer to have this be an OID specified on the IETF or CABForum OID arc. That is what they are for. Since the EV oid has to be CABForum, they might as well do the null OID.
> 
> The question there would become, why would you want to use such a directive? Wouldn't not wanting a certificate be a consequence of not wanting the domain to be used in any context whatsoever? So maybe there should be some use of flags to say 'don't issue, don't rely, don't contact any service at'

Just to be clear about my earlier message: I was talking about use cases and the protocol for DANE, not for CAA. CAA is being developed outside the IETF and is, of course, free to add or not add whatever use cases it wants. The thread here is whether we can add such use cases for DANE; I still think the answer is "yes".

--Paul Hoffman

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 17 May 2011 00:00:48 -0400

You are incorrect.

Please do not make unfounded claims here.

On Mon, May 16, 2011 at 11:01 PM, Paul Hoffman <[email-masked]>wrote:

> > I would prefer to have this be an OID specified on the IETF or CABForum
> OID arc. That is what they are for. Since the EV oid has to be CABForum,
> they might as well do the null OID.
> >
> > The question there would become, why would you want to use such a
> directive? Wouldn't not wanting a certificate be a consequence of not
> wanting the domain to be used in any context whatsoever? So maybe there
> should be some use of flags to say 'don't issue, don't rely, don't contact
> any service at'
>
> Just to be clear about my earlier message: I was talking about use cases
> and the protocol for DANE, not for CAA. CAA is being developed outside the
> IETF and is, of course, free to add or not add whatever use cases it wants.
> The thread here is whether we can add such use cases for DANE; I still think
> the answer is "yes".
>
> --Paul Hoffman
>
>

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 16 May 2011 21:22:46 -0700

> You are incorrect.

For the benefit of the WG, after I sent the last message, I saw that Phill had proposed that CAA become a work item in the PKIX WG. I apologized to him offline for sending my mail to the DANE WG before reading all of the mail for each WG I follow.

Be that as it may, my statement is still correct: CAA is not being worked on in the IETF. It might be in the future, such as if the PKIX WG adopts it as a work item. In such a case, the DANE WG should probably coordinate with that work. If CAA doesn't get adopted in an IETF WG, the DANE WG should still consider it if we do anything that might overlap with it, even if CAA is just an experimental protocol.

--Paul Hoffman

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 17 May 2011 09:03:51 -0400

I only noticed Paul's offlist comment after I posted my reply.

But he is still wrong. Unless we have Note Well completely wrong (and need
to fix it urgently) all Internet Drafts are 'In IETF Process'. Drafts can
and do become RFCs without going through a Working Group. Drafts can even
become standards without a WG being formed.

The plan with CAA was always to make it a standards track proposal. The
reason it was proposed in the way it was is that at a minimum it has to
interface with PKIX and DNSEXT in IETF and CABForum outside IETF. In
addition the proposal has implications for TLS, HTTP possibly IPSEC and of
course DANE.

When dealing with that type of situation I want to minimize the number of
interfaces before proceeding. So it was designed to anticipate input from
PKIX (i.e. use OIDs) and HTTP (i.e. make it congruent with a tagged header
approach) and proposed in a form that allowed discussion of the DNS
interface in the hope of getting that out of the way first.

Although the concept for CAA was only developed late last year, I have been
working on various 'properties in DNS' proposals for two years now. So CAA
is presented in an extension framework that is designed to support more that
just authorization records.

The ultimate goal is to support a socket API of the following form

TCPSocket Socket = new TCPSocket ("example.com", "_http._tcp")

Which would automatically return the 'best' connection for HTTP that is
offered by example.com.

The reason for wanting to support such an interface is that it is really
difficult to support callbacks or delegates in a scripting language and
security policy attributes are probably not things that should be defined at
the application level anyway.

One consequence of this objective is that I have been looking at libraries
for DNS interfaces in the major programming languages and we have a serious
problem. None of the major platforms currently in use has a real DNS API in
the standard libraries.

>From here I can see three possible outcomes

1) Do nothing, let two separate properties in DNS mechanisms develop, one of
which is almost certain to wither on the vine.

2) Design DANE to support general purpose 'connection properties in DNS' and
rewrite CAA to express the policy and path properties in whatever
framework/record DANE develops.

3) Design DANE as an extension of the CAA approach (see GSRV/ESRV for how
this could work).

On Tue, May 17, 2011 at 12:22 AM, Paul Hoffman <[email-masked]>wrote:

> For the benefit of the WG, after I sent the last message, I saw that Phill
> had proposed that CAA become a work item in the PKIX WG. I apologized to him
> offline for sending my mail to the DANE WG before reading all of the mail
> for each WG I follow.
>
> Be that as it may, my statement is still correct: CAA is not being worked
> on in the IETF. It might be in the future, such as if the PKIX WG adopts it
> as a work item. In such a case, the DANE WG should probably coordinate with
> that work. If CAA doesn't get adopted in an IETF WG, the DANE WG should
> still consider it if we do anything that might overlap with it, even if CAA
> is just an experimental protocol.
>
> --Paul Hoffman
>
>

---

From: Yoav Nir <[email-masked]>
Date: Tue, 17 May 2011 16:12:21 +0300

That would work for CAA, but you can't use the same record for the relying party, and again you need to types of records.

I don't think it makes much difference whether there is a CAA sub-type to the DANE type, or whether CAA is its own type. 

-----Original Message-----
From: Richard L. Barnes [mailto:[email-masked]] 
Sent: 16 May 2011 16:52
To: Yoav Nir
Cc: Paul Wouters; Paul Hoffman; IETF DANE WG list
Subject: Re: [dane] cert authority authz (was: Starting WGLC on: draft-ietf-dane-use-cases-02)

>> If it does become a dane use case, then like I suggested for the CAA 
>> record, there should be a valid "null record" to state that no CA 
>> should issue/be trusted. This would be to avoid people using "bogus" data to accomplish the same.
>