Picking this up after a long gap... On Sat, Jul 8, 2017 at 4:44 AM, Hugo Landau <[email protected]> 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 protected]", 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 protected]" gets popular enough that "example.com" and "example.net" also start using it? --Richard > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
