The signature construction is a little worrying. about acme-spec HOT 4 CLOSED

This is a very good point. I think the simplest thing to do here may be to just use the JOSE signature scheme, with the nonce as a protected header parameter. With that, the input the signature algorithm for a given nonce and payload would be:

base64("{\"nonce\":base64(nonce)}) || . || base64(payload)

This is especially appealing now that JWS has a simpler syntax for JSON-formatted objects. With that, a JWS would be nearly as simple as what's there today.
https://tools.ietf.org/html/draft-ietf-jose-json-web-signature-36#section-7.2.2

Could you please file the "different key pair" issue as a separate issue?

from acme-spec.

JOSE protected header seems like overkill. Restricting nonces to 16 bytes doesn't sound particularly future-proof. What about prepending the nonce length?

from acme-spec.

Switching to JWS does solves this problem and would not require fixing the nonce length. An alternative to including the nonce in the JWS Protected Header is to make the signature payload a (stringified) JSON object that includes the "nonce" key+value as well as the other values being signed over. This would avoid other attacks of the kind described by @agl. If the signature is valid, it is a simple matter for the server to decode the payload and check that the nonce and other inputs match expected values.

Heck, you could even sign the whole response object if you wanted (minus those bits that are part of the signature construction).

It is a sensible move anyway - why devise a new signature scheme instead of using an existing one? I don't buy the argument that it is overkill.

from acme-spec.

The use of JWS is sufficient to address this problem.

from acme-spec.