+1 - this seems like something we should have had already. Thanks for catching & proposing the fix Rob.
On Thu, Jan 24, 2019 at 9:30 AM Richard Barnes <r...@ipv.sx> wrote: > This seems fine to me. It's basically just a table entry, with some > description of how to use it. > > --Richard > > On Thu, Jan 24, 2019 at 9:26 AM Rob Stradling <r...@sectigo.com> wrote: > >> I realize it's very late for making non-editorial changes to >> draft-ietf-acme-acme, but I'd like to propose adding a new badPublicKey >> error. This error would be returned by the server whenever it does not >> support, or wishes to reject, a "jwk" public key supplied in a client's >> request. >> >> Proposed text: https://github.com/ietf-wg-acme/acme/pull/478 >> >> The 'array of supported "alg" values' in a badSignatureAlgorithm >> response is useful, but ISTM that it doesn't provide detailed enough >> information to assist a client in generating a suitable public key. >> >> (If the consensus is that it's too late to add a new error type, then my >> alternative proposal will be to use "malformed" instead of adding >> "badPublicKey", but keep the rest of PR 478 as is; I think it's a good >> idea to call out the need for a server to sanity check each >> client-supplied public key). >> >> -- >> Rob Stradling >> Senior Research & Development Scientist >> Sectigo Limited >> >> _______________________________________________ >> Acme mailing list >> Acme@ietf.org >> https://www.ietf.org/mailman/listinfo/acme >> > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
