Subject: Re: [Acme] URI-based CAA account binding

From: Richard Barnes <[email-masked]>
Date: Sun, 2 Oct 2016 10:24:34 -0400

Thanks for the draft, Hugo.  In general, the idea of making CAA more
precise seems like a good vein to explore, and to the dimensions of
precision overlap with ACME semantics, it makes sense to do it here.

The other case (besides account URI) that I've heard folks talk about is
allowing the domain holder to restrict what validation methods the CA
should be allowed to use.  For example, you might allow DNS validation and
forbid HTTP validation.  Between ACME and the new, stricter Baseline
Requirements, it seems like we should be able to come up with a pretty
comprehensive list of validation methods.  Is this something that would
make sense to fold into this document?

On Sat, Sep 24, 2016 at 11:09 PM, Hugo Landau <[email-masked]> wrote:

> This is an updated version of my previous draft. Comments invited.
>
> https://hlandau.github.io/draft-landau-acme-caa/
>
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>

---

From: Hugo Landau <[email-masked]>
Date: Mon, 3 Oct 2016 01:29:18 +0100

>    make sense to fold into this document?

Alright, so here's some ideas:

-  An ACME-specific 'acme-methods' parameter taking a comma-separated
   list of methods (e.g. "acme-methods=dns-01,http-01").

-  A generic "method-uri" parameter which accepts a URI representing a
   method. For ACME this would be urn:ietf:acme:method:METHOD-NAME.
   Multiple methods would probably be specified via multiple CAA
   records; this would be slightly more obtuse for implementations
   to process than the above, but nothing unreasonable.

There's also the question of whether this should be in the same I-D or a
separate one. I'm fine with putting it in, but if anyone thinks it
should be a separate I-D, let me know.