Re: [Acme] AD Review: draft-ietf-acme-caa-05

[Eric Rescorla <[e-mail]>]

This SGTM. ACME editors?

-Ekr


On Sat, Dec 22, 2018 at 8:28 AM Hugo Landau <[e-mail]> 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.
>