Subject: [Acme] Use of CAA in ACME

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 3 Feb 2016 14:17:24 -0500

I would like to propose that we use RFC6844 to allow clients to
discover the CA to direct requests to.

A DNS name MAY have multiple CAA records. Each record has a tag
specifying the purpose and a text field. So we would add in a text
field for ACME.

The simplest version would be something of the form:

example.com CAA 0 acme "comodo.com"

The typical enterprise case has the request going to an LRA because
that is where the account key pair is held and that is what did the
validation against the CA.

I am thinking through that part.

---

From: Richard Barnes <[email-masked]>
Date: Wed, 3 Feb 2016 15:42:55 -0500

This seems like a fine idea.  You would need either a way to map from
domain names to ACME server URLs, or a new CAA record type to hold the
URL.  I would honestly kind of prefer the former, to avoid confusion.

I would also like to have a CAA record type for authorizing validation
methods, so that a domain holder can request that CAs only use certain
validation methods, regardless of what the ACME client requests.

Both of these ideas are good targets for a separate spec, since it's pretty
well decoupled from ACME itself.

On Wed, Feb 3, 2016 at 2:17 PM, Phillip Hallam-Baker <[email-masked]>
wrote:

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

---

From: Hugo Landau <[email-masked]>
Date: Thu, 4 Feb 2016 03:15:07 +0000

So here's a list of issues to be satisfied for CAA:

1. Maybe say that ACME CAs SHOULD use CAA.

2. Provide a standardized ACME account key binding parameter for CAA records.

3. Allow discovery of the correct ACME CA 'issuer' value from an ACME
   directory URL.

4. If we suppose that the CAB Forum determination that challenges
   should be nondeterministic might someday get overturned, there are
   various ways issuance could be authorized via DNS.  One is using CAA.
   Due to the nature of CAA, this would authorize an account key thumbprint
   for an entire domain hierarchy.

   My main reservation about this approach is that it changes the CAA
   semantics from being necessary to sufficient. I can't immediately
   see any issue with this, but it seems like a substantial change, and
   to some extent is an 'overloading' of the CAA record.

   Another possibility is modifying dns-01 to be deterministic, or doing
   things with DANE, however this would only apply to a single name.

5. If I think I am understanding this right, the idea is that an
   enterprise runs its own ACME server which essentially proxies requests
   to the real ACME server.

   I really don't think the CAA record is the right place for this. The
   CAA record is a means of communication from a domain to CA, not from
   a domain to its subsidiary components.

   I think what you are essentially saying is that ACME clients might
   be modified so that they use either a configured or autodiscovered
   organizationally specific directory URL.

   You could reuse the CAA discovery rules of finding the nearest CAA
   record in the tree, only for something like this:

   _acme-server.example.com. IN TXT "https://foo.example.com/directory"

   Whether or not CAA is used, a directory URL should be used and not
   a domain name. Note that the "domain; params" syntax applies only
   to the issue and issuewild tags. iodef, for example, uses an URI.

I covered #3 in PR#72.

I have an unsubmitted change here
<https://github.com/hlandauf/acme/commit/3a91fccd2fef8fc5a966beac95837500c32c2788>
which covers #1, #2 and #4. I haven't submitted it yet because I'm a bit
ambivalent about the sufficiency part. Might want to consider that
separately.

Hugo Landau