Subject: Re: [Acme] Consensus -- CAA draft to WGLC?

From: Yaron Sheffer <[email-masked]>
Date: Wed, 5 Jul 2017 22:45:20 +0300

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
>
> On Wed, Jul 5, 2017 at 11:47 AM, Salz, Rich <[email-masked]> 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.
>>
>>
>

---

From: Richard Barnes <[email-masked]>
Date: Wed, 5 Jul 2017 17:17:34 -0400

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 <[email-masked]> wrote:

> 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.
>
> 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:
>
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 6 Jul 2017 00:48:08 +0300

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 <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     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>
>
>         On Wed, Jul 5, 2017 at 11:47 AM, Salz, Rich <[email-masked]
>         <mailto:[email-masked]>> wrote:
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/acme>
>
>

---

From: Richard Barnes <[email-masked]>
Date: Wed, 5 Jul 2017 18:43:59 -0400

On Wed, Jul 5, 2017 at 5:48 PM, Yaron Sheffer <[email-masked]> wrote:

> 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.
>
> "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.
>

You could also set aside a vendor prefix (e.g., "vnd-", "ca-") that ACME
stuff would be ruled out of.  But your proposed solution seems better to me
in light of the lessons of of RFC 6648.

https://tools.ietf.org/html/rfc6648

> of "use this specific CA AND only with this method". There are probably

I was about to say that such users could just specify an "issue" directive
and a "validation-methods" directive, but the CAA spec is actually unclear
on how the rules combine.  I suppose that's because CAA right now is really
only a CA whitelist, so there's no need for combining.

If we want the CAA "tag" space to be extensible, it seems like there needs
to be an update to the CAA spec to decide this.  ISTM the conservative rule
would be "You must satisfy one rule of each tag type; if you don't
understand a tag type, don't issue".  That would create the semantic I
mention above.  That part should probably go into a separate minor update
spec, though, not in this spec.

--Richard

>> Note that the ACME challenge type values are already registered.  Would
>> it be sufficient to say something like "Tokens registered as ACME challenge
>> 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".
>>
>>
>>