Re: [Acme] HTTP/J Draft

[Fraser Tweedale <[e-mail]>]

On Thu, Feb 26, 2015 at 08:15:57AM -0500, Phillip Hallam-Baker wrote:
> 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).
> 
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.

> 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 <[e-mail]> wrote:
> 
> > 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
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/acme
> >
> >