On Fri, Jul 7, 2017 at 9:33 AM, Hugo Landau <hlan...@devever.net> wrote:
> > On Thu, Jul 6, 2017 at 11:57 AM, Salz, Rich <[1]rs...@akamai.com> > wrote: > > > > So let's see. Can we live with this? > > > > 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". > 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. > 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
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
