The problem with saying "Tokens registered as ACME challenge types MUST
NOT be used to identify non-ACME validation methods" is that ACME might
want to come up with additional method names in the future, and those
just might happen to conflict with methods that have been used by other
organizations in the meantime. This is exactly the kind of mess that
IANA is designed to prevent.
A simple way to go around this issue is if we changed the draft to use
"acme-dns-01" instead of "dns-01" and similarly for all ACME methods.
Then we COULD say that non-ACME CAs MUST not use "acme-*" methods.
To your second point, many enterprise users will want the extra security
of "use this specific CA AND only with this method". There are probably
other use cases though.
Thanks,
Yaron
On 06/07/17 00:17, Richard Barnes wrote:
Just for context here: I think the original operating model for CAA
was that the CA would tell the customer what values to put in there in
order to authorize issuance. So it was safe to use arbitrary values
because it was basically a closed loop CA -> Customer -> CAA -> CA.
Nonetheless, I sympathize with your point here. With ACME, we're
moving things in a more standardized / automated direction, so we can
automate out some of the CA interaction around CAA if we standardize
some values.
Note that the ACME challenge type values are already registered.
Would it be sufficient to say something like "Tokens registered as
ACME challenge types MUST NOT be used to identify non-ACME validation
methods"?
---
This reminds me a related point that I forgot in my initial review.
It would be nice if it were possible to specify a validation method
policy independent of CA. So I wouldn't have to authorize each CA I
interact with individually, but I would be able to say "Only validate
my domains using dns-01".
In fact, is there any reason to have different validation methods per
CA? It's a property of the domain owner / certificate applicant, not
the CA. Is there a reason you would trust CA X to do "http-01" but not
CA Y? (I totally understand why "account-uri" is CA-specific, though.)
I would suggest pulling out "validation-methods" from being an
attribute to being a "tag" / "property", parallel to "issue" and
"issuewild".
On Wed, Jul 5, 2017 at 3:45 PM, Yaron Sheffer <yaronf.i...@gmail.com
<mailto:yaronf.i...@gmail.com>> wrote:
I support moving forward with the document.
However I think the treatment of the acme-methods (or
validation-methods) param is inconsistent, before and certainly
after Richard's PR. The original draft only allows ACME methods
and the special name "non-acme". This leaves the responsibility to
ensure names are well defined with the IETF.
If we allow mixing ACME methods with CA-defined methods per
Richard's proposal, we should make sure that there is no overlap.
And even if names are defined by individual CAs, the CA should
provide a precise definition of each validation method. IMO there
are two good options:
- Define an IANA registry for the validation-methods values. (This
is simple enough, and would be my preference).
- Define an IANA registry for prefixes (such as "cabf" mentioned
in Richard's text) and specify that everything else must be
defined by ACME.
Thanks,
Yaron
https://github.com/ietf-wg-acme/acme-caa/pull/2
<https://github.com/ietf-wg-acme/acme-caa/pull/2>
On Wed, Jul 5, 2017 at 11:47 AM, Salz, Rich <rs...@akamai.com
<mailto:rs...@akamai.com>> wrote:
There's no listing going on here, since there's no
registry for the
values. CABF could put tokens in their documents if they
like.
Okay, please propose wording (or did you? Sorry if so) to
change for the
CAA draft.
_______________________________________________
Acme mailing list
Acme@ietf.org <mailto:Acme@ietf.org>
https://www.ietf.org/mailman/listinfo/acme
<https://www.ietf.org/mailman/listinfo/acme>
_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
