From: Hugo Landau <[email protected]>
To: Richard Barnes <[email protected]>
Cc: [email protected]
Subject: Re: [Acme] URI-based CAA account binding
Message-ID: <[email protected]>
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
[email protected]
https://www.ietf.org/mailman/listinfo/acme
