Subject: [Acme] HTTP/J Draft

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 25 Feb 2015 22:14:03 -0500

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

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.

---

From: Fraser Tweedale <[email-masked]>
Date: Thu, 26 Feb 2015 14:37:18 +1000

> 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

> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 26 Feb 2015 08:15:57 -0500

Yes, Base64 is a deal breaker.

Try reading the JWS specs and it is impossible to make sense of them
because they are just a series of base64 blobs.

There is zero point in using a text encoding and then making it impossible
to read.

On the detached signature side yes, it is going to be some sort of detached
mode and if JWS can't do that we can use something else (the section you
link to is incoherent).

Let us make things easy here. A digital signature signs a stream of bits,
so that signed stream of bits should appear in the protocol message.

JWS is still a big improvement on the XML signature lunacy with XPATH and
XSLT to allow the signature to turn the document inside out. Bletch.

On Wed, Feb 25, 2015 at 11:37 PM, Fraser Tweedale <[email-masked]> wrote:

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

---

From: Fraser Tweedale <[email-masked]>
Date: Fri, 27 Feb 2015 13:12:36 +1000

> mode and if JWS can't do that we can use something else (the section you
It states that there is no explicit support in JWS for a detached
signature mode, and that it is the application's responisbility to
remove and restore the payload to the appropriate place in the JWS
Serialization before processing.

It is straightforward, and IMO preferable to a custom signature
construction.

---

From: Tony Arcieri <[email-masked]>
Date: Thu, 26 Feb 2015 19:48:04 -0800

> It is straightforward, and IMO preferable to a custom signature

+1 for using standards
-1 for a custom signature construction

-Someone who has read the JOSE/JWE/JWS/JWT specifications and isn't super
impressed but thinks they're fine

-- 
Tony Arcieri