This SGTM. ACME editors?
-Ekr
On Sat, Dec 22, 2018 at 8:28 AM Hugo Landau <hlan...@devever.net> wrote:
> > I'm open to alternative methods of preventing conflicts. A prefix could
> > > be reserved for CA-specific use, e.g. "nonacme-".
> > >
> >
> > That would be fine.
>
> Amended to:
>
> Where a CA supports both the "validationmethods" parameter and one or
> more non-ACME challenge methods, it MUST assign identifiers to those
> methods. If appropriate non-ACME identifiers are not present in the
> ACME Validation Methods IANA registry, the CA MUST use identifiers
> beginning with the string "nonacme-". Such identifiers have
> CA-specific meaning.
>
> Attention should be drawn to the following text in the ACME I-D:
>
> When evaluating a request for an assignment in this registry, the
> designated
> expert should ensure that the method being registered has a clear,
> interoperable definition and does not overlap with existing validation
> methods.
> That is, it should not be possible for a client and server to follow the
> same set of actions to fulfill two different validation methods.
>
> Validation methods do not have to be compatible with ACME in order to be
> registered. For example, a CA might wish to register a validation
> method in
> order to support its use with the ACME extensions to CAA
> {{?I-D.ietf-acme-caa}}.
>
> Since this is a prefix and not an entry per se, it seems like the
> cleanest way to accommodate this is to amend the ACME I-D, rather than
> use of "IANA Considerations" section, which is currently nil. The ACME
> I-D is already referencing ACME-CAA above. But I'm open to suggestions.
>
_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
