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

From: Richard Barnes <[email-masked]>
Date: Wed, 5 Jul 2017 11:42:44 -0400

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.

On Tue, Jun 13, 2017 at 1:33 PM, Salz, Rich <[email-masked]> wrote:

> > The two last ones are editorial, but the first about enumerating all BR
> > methods isn't (since it needs new validation method identifiers).
>
> Thinking about it a bit more, I don't think it is appropriate for ACME to
> list CABF things.  That's a strong view as an individual, and a moderate
> view as a WG chair.
>

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 5 Jul 2017 15:47:11 +0000

> 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 12:41:20 -0400

https://github.com/ietf-wg-acme/acme-caa/pull/2

---

From: Hugo Landau <[email-masked]>
Date: Thu, 6 Jul 2017 11:07:02 +0100

>    [1]https://github.com/ietf-wg-acme/acme-caa/pull/2

1. I'm not sure what the point of changing "acme-methods" to
"validation-methods" is. It still has the "non-acme" value, so it's
clearly defined in relation to ACME.

(Even if it wasn't, how is this namespace supposed to be defined? Should
an IANA registry be requested rather than reusing the ACME validation
methods registry? If so, it creates the possibility of divergence
between the ACME methods registry and the validation methods registry.
That, in turn, could be solved via some sort of inheritance between the
two registries, but that would require changes to the ACME validation
method registry, insofar that if someone registers string X in the
ACME-CAA validation method registry for something unrelated to ACME,
string X cannot thereafter be registered as an ACME validation method.
Since this would restrain the ACME validation methods registry, consent
would need to be obtained for this.)

I see some of these concerns have already been mentioned. The prefix
registry proposal works: Have an "acme" prefix which accesses the ACME
validation methods namespace, e.g.
"validation-methods=acme:dns-01,acme:tls-sni-02,cabf:foo".

There could be an "unknown" value which would represent any validation
method without an assigned identifier - but now that I think about it,
since this structure would enable all parties to assign identifiers to
even legacy validation methods, that seems like an unnecessary footgun.

Vendor-assigned identifiers could be supported as such:
  vnd:example.com/custom-method

But now we're reinventing URIs. So perhaps we should just switch to URIs
and define an URN mapping for ACME validation methods. I'd support that.

To summarise, I think we should keep "acme-methods" (and rely on the
extensibility of CAA at the parameter level where non-ACME validation
method constraints are to be expressed) or replace it with
"validation-methods" taking a list of URIs (and defining a mapping from
ACME validation method names to URNs).

2. Adding a reference to CABF is weird because it references a policy
body. This is quite orthogonal to the IETF's mission, and these things
should probably be kept separate. Since all commercial CAs need to be
aware of the requirements of the CA/Browser forum anyway, the utility of
this statement seems to be zero, and unnecessarily politicises the
standard (for some value of politics).

3. Changing CA A to CA X, etc. is fine.

(Splitting this up into multiple PRs would probably be desirable.)

---

From: Martin Thomson <[email-masked]>
Date: Thu, 6 Jul 2017 20:16:55 +1000

>   vnd:example.com/custom-method

RFC 6648 explains why vendor-prefixes can be a bad idea.  I think that
you should do as Yaron suggested and establish a registry.  Set the
bar low (specification required would be my choice) and then CABF can
make a new entry as they see fit.  In particular, do away with
attaching some sort of semantic to prefixes.

> 2. Adding a reference to CABF is weird

This I agree with.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 6 Jul 2017 15:57:14 +0000

So let's see.  Can we live with this?

Create a spec-required registry for validation method names.

Do not reference CABF docs.

Change the CA sample names from A B to X Y or foo bar or this that or whatever.

---

From: Richard Barnes <[email-masked]>
Date: Fri, 7 Jul 2017 09:23:19 -0400

> Create a spec-required registry for validation method names.

I share Hugo's concern about divergence here.  Should we maybe just put
these in the ACME challenge types registry?  It is already Spec-Required.
That would mean that not all of those values would be usable with ACME, but
that doesn't seems very likely to lead to interop problems, since a
sensible ACME server wouldn't offer the non-ACME ones.  Or you could just
add a column to indicate ACME / non-ACME.

In any case, if we go down this path, I would suggest we change "non-acme"
to "vendor", in order to signify "something that is not in the registry".

> Do not reference CABF docs.

I don't understand the concern here.  IETF document reference non-IETF docs
all the time.  This seems like useful context.

> Change the CA sample names from A B to X Y or foo bar or this that or

This is already in my PR.  I updated the PR with the "vendor" stuff above:

https://github.com/ietf-wg-acme/acme-caa/pull/2/commits/e40c9cb7cfdf34b6fd2b4e0017ae626105287f58

--Richard

---

From: Hugo Landau <[email-masked]>
Date: Fri, 7 Jul 2017 14:33:13 +0100

>    On Thu, Jul 6, 2017 at 11:57 AM, Salz, Rich <[1][email-masked]> wrote:
> 
>    That would mean that not all of those values would be usable with ACME,
>    but that doesn't seems very likely to lead to interop problems, since a
In this case we may as well keep it called "acme-methods" and leave the
extension of that namespace (ACME challenge method names) to non-ACME
things to the future.

---

From: Richard Barnes <[email-masked]>
Date: Fri, 7 Jul 2017 09:57:00 -0400

> extension of that namespace (ACME challenge method names) to non-ACME

The future is now!  :)

https://github.com/ietf-wg-acme/acme/pull/332

Even if we don't make the ACME change, if we think that some day there
might be non-ACME identifiers in this CAA field, then I would propose that
we use "validation-methods" instead of "acme-methods", for future-proofing.

--Richard

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 7 Jul 2017 14:51:39 +0000

> https://github.com/ietf-wg-acme/acme/pull/332

I like this.  I proposed one minor wording clarification.

---

From: Hugo Landau <[email-masked]>
Date: Sat, 8 Jul 2017 09:44:28 +0100

> > https://github.com/ietf-wg-acme/acme/pull/332
Alright, if the ACME spec wants to genericise its validation methods
registry, I'm okay with the validation-methods change as-is.

Questions:

1. Should we drop "non-acme", since any non-ACME method can have its own
   identifier listed? I think probably.

2. An ACME validation method, such as http-01, can only be used in the
   context of using ACME. Conversely, should non-ACME validation methods
   only be usable in non-ACME contexts?

   For example, suppose someone registered a "cabf-dv-http" validation
   method generically referring to CABF-compliant HTTP-based DV.
   If someone wants to use ACME, they can list http-01 specifically,
   so I think ACME CAs should ignore method specifiers like this.
   These method names would be applicable solely to non-ACME CAs.

   (This is sort of implied already by the subtext that an act of
   validation has exactly one validation method name applicable to it,
   but we could be clearer about this.)

With regard to ACME-CAA PR#2: Is a "vendor" validation method, rather
than a prefix, really that useful?

RFC6648 deprecates prefixes like "x-", but thinks that vendor-specific
prefixes like domain names are still OK. So we could amend the ACME
specification allowing challenge method names of the form
"[email-masked]", say (this is inspired by SSH capability names). This
would have utility for vendors both in and outside of the context of
ACME-CAA.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 10 Jul 2017 20:26:29 -0400

> > 2. Adding a reference to CABF is weird

​CAA already has a tag registry. The bar to entry is deliberately low. If
you really can't use the existing registry, use the existing one as a
template.

But the thing with DNS records is that you have a left hand side (domain
name, record type) and a right hand side (record data) and the DNS protocol
only allows you to select on the left hand side.

If you do a CAA query, you are always going to get back the full set of
records. ​So you are always going to have to look at them all.

CAA tags are text labels with a deliberately generous number of
possibilities. We are not going to run out. Rather than create a
subordinate registry, I would prefix within the label.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 10 Jul 2017 20:30:50 -0400

x- prefixes were for experimental. They are bad because they inevitably
fail. either the experiment fails and is forgotten or it succeeds and all
the software has to check for both in perpetuity. Its just bad. Do not do.

acme-foo
acme-bar
etc.

Is a totally different proposition. That is a good thing provided that you
don't go expecting the software to treat these as anything other than
opaque labels. As it won't.

On Sat, Jul 8, 2017 at 4:44 AM, Hugo Landau <[email-masked]> wrote:

> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>