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
