Would like to see proposed wording, but the concept seems fine. From: Eric Rescorla <e...@rtfm.com> Date: Saturday, December 22, 2018 at 12:26 PM To: Hugo Landau <hlan...@devever.net> Cc: "acme@ietf.org" <acme@ietf.org> Subject: Re: [Acme] AD Review: draft-ietf-acme-caa-05
This SGTM. ACME editors? -Ekr On Sat, Dec 22, 2018 at 8:28 AM Hugo Landau <hlan...@devever.net<mailto: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
