Re: [Acme] ACME signature mechanics

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 ;)

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.

On Tue, Dec 16, 2014 at 4:22 AM, Anders Rundgren <
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
> https://www.ietf.org/mailman/listinfo/acme
>