We could add a new error type and accompany the problem document with an extra field that defines the valid reason codes à la the 'alg' field that is added when we return 'badSignatureAlgorithm'.
On 02/16/2017 08:16 AM, Daniel McCarney wrote: > +1 - I think this is clearer. > > Would you be open to specifying what form the rejection takes? Do you > think it > would be advantageous to specify a new error in Section 5.7 for the purpose > (e.g. `urn:ietf:params:acme:error:invalidReasonCode`) or is there an > existing > candidate you'd use? > > > On Tue, Feb 14, 2017 at 5:53 PM, Roland Bracewell Shoemaker > <[email protected] <mailto:[email protected]>> wrote: > > The current draft leaves it ambiguous as to what the server should do > when a it receives a revocation request containing a reasonCode that it > disallows. I suggest we add a simple 'MUST reject request' clause to the > relevant section to resolve this ambiguity. > > PR: https://github.com/ietf-wg-acme/acme/pull/251 > <https://github.com/ietf-wg-acme/acme/pull/251> > > _______________________________________________ > Acme mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/acme > <https://www.ietf.org/mailman/listinfo/acme> > > _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
