From: Hugo Landau <hlan...@devever.net>
To: Richard Barnes <r...@ipv.sx>
Cc: acme@ietf.org
Subject: Re: [Acme] URI-based CAA account binding
Message-ID: <20161003002918.ga5...@andover.lhh.devever.net>
Content-Type: text/plain; charset=iso-8859-1

   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?

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.


I support this idea for the reasons listed here: https://tools.ietf.org/html/draft-sheffer-lurk-cert-delegation-00#section-4.3.

I think the first option (ACME-specific parameter) is preferred, because it is much better defined. I would suggest to include it in the current document, and with strict semantics: an ACME implementation that supports CAA MUST understand this parameter and MUST NOT use any method not listed here.

Thanks,
        Yaron

_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Reply via email to