As WG co-chair, I am not thrilled with making this addition so very very late in the process. If the WG wants to do it, we'd need (a) clear consensus and (b) a quick approval from the IESG.
As an individual, I dislike putting "here's what's wrong with your key" in the error message. For example, it encourages a thief to do "venue shopping" looking for a CA that will certify their stolen keypair. On 1/24/19, 9:27 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