Subject: [pkix] CSRs in CAA

From: Matt McCutchen <[email-masked]>
Date: Fri, 03 Jun 2011 17:30:47 -0400

On Fri, 2011-06-03 at 11:46 -0400, Paul Wouters wrote:
> If only we could add a DNS record in our zone and sign it to signifiy what our pubkey is...
> 
> If you're going to trust DNS for anything, you might as well take a hint to grab the pubkey
> needed from the cert. So CAs could just confirm the incoming cert request by doing a DNS
> lookup of the pubkey.

For those who want to support legacy clients while making the maximum
possible use of DNS, this is absolutely the thing to do, except I would
use the CSR or even (CSR, requested signer cert).  This is just to
authenticate the entire request; the CA may only honor a subset of the
CSR fields according to its policies.

Organizations that have a close relationship with a CA may not feel the
need to duplicate their requests to the CA in the DNS, but they may find
the ancestor cert and cert policy constraints to be useful controls.
Hence, I would keep those options as well.

Let's take further discussion of CAA to the PKIX list.

-- 
Matt

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 3 Jun 2011 17:53:33 -0400

I see that as a different use case. Basically that is providing an
additional authentication signal to the CA providing a form of proof of
ownership of the Domain.

We did discuss this type of approach early on in the design of CAA and
decided to punt on it for the initial proposal as the domain name owner can
achieve the same effect by only authorizing a CA after establishing an out
of band agreement to use a particular authentication technique.

Putting a CSR in the DNS is a subset of the possible authentication
techniques and not a good one in my view as it requires the DNS to be
touched on a per transaction basis. That is contrary to my understanding of
the normal approach to DNS administration which is to only put information
in the DNS that is intended to be persisted for a period. Admittedly
certification requests are infrequent events, but even so, it is not a
precedent that I would like to see.

Instead I would prefer to see the DNS used to express credentials that are
already employed in Certificate validation processes. For example an email
address nominated as the contact address or a public key of an authorized
authentication credential.

So I see it as a useful complement to but not a replacement for path and
policy.

An email contact address would be useful even if it was not used for
authentication. Management of the larger Web properties can be very complex
and getting to a security person in a hurry can be a challenge.

On Fri, Jun 3, 2011 at 5:30 PM, Matt McCutchen <[email-masked]>wrote:

> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
>

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

---

From: Matt McCutchen <[email-masked]>
Date: Fri, 03 Jun 2011 22:49:23 -0400

On Fri, 2011-06-03 at 17:53 -0400, Phillip Hallam-Baker wrote:
> additional authentication signal to the CA providing a form of proof
> of ownership of the Domain.

Not really.  It provides proof that the domain owner authorized the
issuance of the particular certificate.  It can be used as either an
alternative validation mechanism or an additional requirement.  Your
description would correspond to publishing the subscriber's username for
the CA's portal.

> decided to punt on it for the initial proposal as the domain name
> owner can achieve the same effect by only authorizing a CA after
> establishing an out of band agreement to use a particular
> authentication technique.

You are right.  The CSR endorsement can be a separate protocol whose use
is specified via CAA; there is no need to standardize both at once.  But
I do strongly desire a standardized protocol for CSR endorsement, so
that the public accountability benefits of CAA can extend down to the
level of the individual certificate.

> touched on a per transaction basis. That is contrary to my
> understanding of the normal approach to DNS administration which is to
> only put information in the DNS that is intended to be persisted for a
> period. Admittedly certification requests are infrequent events,

In fact, they would typically coincide with changes to the TLSA RRset.

> but even so, it is not a precedent that I would like to see.

Good point.  The DNS authority structure is just what we want, but DNS
is not an appropriate transport.  So instead, the CSR could be signed
with a public key published in DNS or even with the DNSKEY itself,
unless that makes people uncomfortable.

> Instead I would prefer to see the DNS used to express credentials that
> are already employed in Certificate validation processes. For example
> an email address nominated as the contact address or a public key of
> an authorized authentication credential.

Mmm... For authentication of requests, you need a public key somewhere,
and then an email address doesn't buy you anything extra.

> authentication. Management of the larger Web properties can be very
> complex and getting to a security person in a hurry can be a
> challenge.

It sounds like the email address is addressing an orthogonal set of
concerns.

-- 
Matt

---

From: Matt McCutchen <[email-masked]>
Date: Fri, 03 Jun 2011 23:05:04 -0400

> CSR fields according to its policies.

Do you all realize what we'll be able to do with such a protocol?  Just
give your web server access to update its DNS data via TSIG, and it can
generate a key pair, poke the DANE records into DNS, and get itself a
domain-validated certificate from your favorite CA.  This functionality
could be in the TLS server library.  (Yes, Martin, I mean "TLS and
associated technologies".)

At a higher level, when you register a domain from $favorite_web_host,
you could check a box and have them set up the whole nine yards: DNSSEC
with DS submitted to the registry, TLS, DANE, a domain-validated
certificate, strict transport security, and whatever else we cook up.
Phill, this may be the "easy TLS adoption" you were looking forward to.

-- 
Matt

---

From: Matt McCutchen <[email-masked]>
Date: Sat, 04 Jun 2011 12:17:12 -0400

On Sat, 2011-06-04 at 09:35 -0400, Phillip Hallam-Baker wrote:
> It does not show the party that is authorized to issue or the key that
> is authorized to sign. 

In place of CSR, read (CSR, requested signer cert) tuple.  In fact, it
might make sense to have an optional field for the requested signer cert
in the CSR itself.  Or does the authority key identifier already serve
this purpose?

-- 
Matt

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 4 Jun 2011 09:35:27 -0400

It does not show the party that is authorized to issue or the key that is
authorized to sign.

It is a different risk for the same use case.

But there is one specific use case for putting a CSR up that is very
compelling and that is to install the CSRs for the ICANN Root Signing KSKs.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 4 Jun 2011 14:17:51 -0400

> in the CSR itself.  Or does the authority key identifier already serve

This is starting to look complicated to me.

I think we can break down the potential properties to:

1) General Controls

Specify the authorized issuer by policy, path
Specify the preferred subject authentication by email, public key
Specify contact information

2) Transaction Specific Controls

Specify {CSR, Issuer} of request

I am not completely opposed to the transaction controls. But they look like
they have to be additional options, not replacements to me.

---

From: Matt McCutchen <[email-masked]>
Date: Sat, 04 Jun 2011 16:58:16 -0400

On Sat, 2011-06-04 at 14:17 -0400, Phillip Hallam-Baker wrote:
> On Sat, Jun 4, 2011 at 12:17 PM, Matt McCutchen
> <[email-masked]> wrote:

Where "issuer" should contain at least the DN and public key (or a hash
covering them), so the system doesn't collapse if there is a DN
collision.  Then the request would specify the entire requested
Certificate structure, except that the "signature" field is left
symbolic as "sign($tbsCertificate, break_rsa($issuer_public_key))".  :P

> I am not completely opposed to the transaction controls. But they look
> like they have to be additional options, not replacements to me.

Absolutely.  

-- 
Matt