[Acme] ACME signature mechanics

["Manger, James" <[e-mail]>]

draft-barnes-acme looks like a promising spec.
https://github.com/letsencrypt/acme-spec/blob/master/draft-barnes-acme.txt


A couple of comments:

1. The bytes to-be-signed for the various messages are the concatenation of a few fields, with no separators.
   signature-input = nonce || content
   signature-input = signature-nonce || identifier || server-nonce
   signature-input = signature-nonce || server-nonce
This looks problematic as the bytes to-be-signed are not unambiguous by themselves. The same signature (eg over ABC) is valid even if bytes are moved from a nonce to the content (eg nonce=A, content=BC; and nonce=AB, content=C). The same signature may be valid when treated as a different type of message (eg signature-nonce=A, identifier=B, server-nonce=C).

Suggestion: signature-input = <len1><field1> || <len2><field2> || ... (where <lenn> is  the length in bytes of the following field, encoded in 8 bytes)

[P.S. Watson Ladd pointed out a similar issue with HOBA earlier today in an email titled "[http-auth] Concatenation is not injective". http://www.ietf.org/mail-archive/web/http-auth/current/msg02053.html]


2. Appending 'path' to '.well-known/acme-challenge' as part of a simpleHttps challenge (section 6.1) looks dangerous if not done carefully. What if 'path' is "../../user/alice/whatever"?

Suggestion: I would be tempted to say: "take the 'path' string value, UTF-8 encode it, base64url-encode those bytes, then append to '.well-known/acme-challenge'".


3. 'nonce' is "at least 16 bytes, base64-encoded" according to section 5.2 "Signatures". Is the base64-encoding removed before using the nonce as part of the signature input?

--
James Manger