Re: [Acme] HTTP/J Draft

On Wed, Feb 25, 2015 at 10:14:03PM -0500, Phillip Hallam-Baker wrote:
> Earlier on this list we discussed the question of how to use JSON to encode
> messages. I think that it would be useful to write this up as a draft.
> 
> I don't particularly care what the rules are but I would like to avoid
> writing a new set of rules for each protocol that comes along. One of the
> main attractions for me in using JSON is that instead of offering five ways
> of encoding a data structure like ASN.1 does or fifty like XML does, there
> is one way to do most things.
> 
> What we don't have convergence on is how to sign JSON data in a protocol
> message. Though this has been discussed on the JSON list a bit as well as
> here.
> 
> 
> Drawing together the earlier discussion points, here are things that I
> think there was broad agreement on:
> 
> 1) The signature covers exactly one data blob which is placed in the
> payload portion of a HTTP message.
> 
> This means no signed headers, no signed request or response line. Any data
> that is significant in the application protocol is carried in the
> application content area.
> 
> 2) The signature data is passed in the HTTP payload section, not as a
> header.
> 
> This means I have to change my code. But I think it is the right thing to
> do. The mixing of content metadata headers and protocol headers is a really
> unlovely feature of HTTP. Putting the signature in the payload section
> raises no implementation difficulties.
> 
> 3) The payload section consists of a signature block followed by some
> record separator mark followed by the signed data. The signed data is
> passed verbatim without base 64 encoding.
> 
> 4) The signature is described using JSON/JOSE
> 
Please be specific about what JWS serialisation(s) are supported.
Are you intending only the JWS Compact Serialization to be used?

Also, I presume you intend that JWS be used in a "detached content"
mode as described at [1], to avoid duplicating the content in both
the JWS object as well as after the "signatures block?

[1] http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-41#appendix-F

Finally, why not just use JWS by itself?  The only advantage I can
see to this construction is that the payload is not Base64-encoded.
Is that an important concern?  Important enough to warrant the
additional complexity over just using JWS?

Cheers,
Fraser

> 
> So a typical message would be something like
> 
> /.well-known/acme/Register POST HTTP/1.1
> Host: example.com
> Content-Length: 230
> 
> { "signatures" : { "signature":
>      "MRjdkly7_-oTPTS3AXP41iQIGKa80A0ZmTuV5MEaHoxnW2
> 
>          e5CZ5NlKtainoFmKZopdHM1O2U4mwzJdQx996ivp83xuglII7PNDi84w
>          nB-BDkoBwA78185hX-Es4JIwmDLJK3lfWRa-XtL0RnltuYv746iYTh_q
>          HRD68BNt1uSNCrUCTJDt5aAE6x8wW1Kt9eRo4QPocSadnHXFxnt8Is9U
>          zpERV0ePPQdLuW3IS_de3xyIrDaLGdjluPxUAhb6L2aXic1U12podGU0
>          KLUQSE_oI-ZnmKJ3F4uOZDnd6QZWJushZ41Axf_fcIe8u9ipH84ogore
>          e7vjbU5y18kDquDg"}
> 
> 
> { "Register" : { ... Acme Stuff ...}
> 
> 
> I see no point in requiring base64 encoding or using any mechanism to allow
> signing of HTTP headers. Put all the protocol related data in one place and
> stick a signature on the front.
> 
> If folk get really upset then maybe we reverse the order and put the
> signature blocks at the end so that a chunking/streaming approach can be
> easily supported. But this adds quite a bit to implementation complexity
> and ACME doesn't need it.

> _______________________________________________
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme