Re: [Acme] ACME signature mechanics

On 2014-12-16 17:27, Richard Barnes wrote:
> I think there might be a middle way here.  I've been musing about making a "Content-Signature" header that just carries a JWS signature over the payload (no HTTP headers).  Since HTTP has to carry the payload bit-exact, there's no c14n nonsense, so this could be much simpler than other HTTP signing proposals.  It's sort of like JCS, except that there is actually a guarantee that the payload stays the same ;)

I see.  This looks possible but is also a bit of a hack since such signatures can only be verified in a HTTP context.  I would stick to your original JWS transition plan.

BTW, JCS does not depend on any c14n nonsense; it only requires that JSON property order is respected by the serializer/deserializer while whitespace is entirely insignificant.  You can even verify pretty-printed signatures!

>
> That said, if your concern is really human readability, I don't think it's a tragedy to make someone copy/paste into a base64 decoder.

Human readability happens on several levels from documentation to debugging.
That headers and payload are disjunct makes these things slightly less appealing.
It also means that you can't make a unified JSON schema for a message object.

But it surely isn't a show-stopper :-)

For KeyGen2 and my payment related work-items the situation is different since these schemes use multiple and wrapping signatures which JWS doesn't handle in a way that I feel would be acceptable.

If the CSR would be rewritten in JSON, ACME would be in a comparable position...

Cheers,
Anders

>
> On Tue, Dec 16, 2014 at 4:22 AM, Anders Rundgren <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>> wrote:
>
>     When the transition to JWS has been made, human-readable ACME messages like
>
>        {
>          "type": "certificateRequest",
>          "csr": "5jNudRx6Ye4HzKEqT5...FS6aKdZeGsysoCo4H9P",
>          "signature": {
>            "alg": "RS256",
>            "nonce": "h5aYpWVkq-xlJh6cpR-3cw",
>            "sig": "KxITJ0rNlfDMAtfDr8eAw...fSSoehDFNZKQKzTZPtQ",
>            "jwk": {
>              "kty":"RSA",
>              "e":"AQAB",
>              "n":"KxITJ0rNlfDMAtfDr8eAw...fSSoehDFNZKQKzTZPtQ"
>       }  }  }
>
>     will rather look like
>
>     {
>       "payload":"<base64>",
>       "protected":"<base64>",
>       "header":<base64>,
>       "signature":"<base64>"
>     }
>
>     Which apart from being ugly JWS also requires a JSON schema validator (or similar
>     mechanism) to work on separate, unpacked parts of the message.
>
>     Although I don't expect this to change, you may (or may not) want to know that
>     clear-text JSON signatures (without the complexity of XML DSig), is not black magic,
>     you only have to use JSON parsers that doesn't "manipulate" input data:
>     https://openkeystore.googlecode.com/svn/resources/trunk/docs/jcs.html#Sample_Signature
>
>     Cheers
>     AndersR
>
>     _______________________________________________
>     Acme mailing list
>     Acme@ietf.org <mailto:Acme@ietf.org>
>     https://www.ietf.org/mailman/listinfo/acme
>