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

From: Richard Barnes <[email-masked]>
Date: Thu, 19 Oct 2017 13:24:10 -0400

Picking this up after a long gap...

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

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

Yes, I agree.

> 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?
>

I mean, in principle, you could use the ACME methods with something else,
as long as you defined what public key / nonce to use.  But it would be
non-trivial.

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

This raises a good point with regard to the ACME PR.  These labels should
identify *specific* validation mechanisms, so that there's no overlap.  So
you wouldn't want a general label for any CABF-compliant validation
technique; you would want them for specific, interoperably-specified
techniques.  I've added some notes to the ACME PR to try to clarify this.

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

It seems like something we're likely to need at some point, given that
there's still some diversity in validation methods.  But if you're
uncomfortable, I think we can drop it from the CAA PR and handle it later
if it's needed.

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

I think you still run into the "x-" problem here.  What happens when "
[email-masked]" gets popular enough that "example.com" and "example.net"
also start using it?

--Richard

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

---

From: Hugo Landau <[email-masked]>
Date: Thu, 19 Oct 2017 19:21:25 +0100

> uncomfortable, I think we can drop it from the CAA PR and handle it later
Sounds good to me.

> [email-masked]" gets popular enough that "example.com" and "example.net"
Then example.com is immortalised in history as a pioneer of that de
facto standard - there's no issue here, is there? SSH uses
[email-masked] identifiers for extensions, but there's no
implication that only example.com will implement those extensions, on
the contrary. Nor is the XML namespace "http://www.w3.org/1999/xhtml" is
intended to only be used by the W3C.

It would be very helpful if you could base comments on the current I-D:
  https://tools.ietf.org/html/draft-ietf-acme-caa-03
i.e., what diffs would you propose against this I-D?

Yours,
Hugo Landau

---

From: Richard Barnes <[email-masked]>
Date: Thu, 19 Oct 2017 17:24:11 -0400

> i.e., what diffs would you propose against this I-D?

Oh, sorry, I hadn't realized you had updated the draft in the meantime.  I
think for purposes of this discussion, what's in the draft now is fine.
I'll close my PR.

--Richard