Re: [Acme] Signing HTTP Messages

[Richard Barnes <[e-mail]>]

On Mon, Dec 22, 2014 at 6:18 PM, Manu Sporny <[e-mail]>
wrote:
>
> On 12/20/2014 12:32 PM, Richard Barnes wrote:
> > Just for context, here's the equivalent using JWS and protecting only
> > the body:
> >
> > ---------------------
> > POST /foo HTTP/1.1
> > Host: example.org <http://example.org/>
> > Date: Tue, 07 Jun 2014 20:51:35 GMT
> > Content-Type: application/json
> > Digest: SHA-256=X48E9qOokqqrvdts8n...yWxBf7kbu9DBPE=
> > Content-Signature: { "header": { "kid": "Test", "alg": "RS256" },
> > "signature": "jgSq...78w" }
> > Content-Length: 18
> >
> > {"hello": "world"}
> > ---------------------
> >
> > Note that using JWS means that I can just toss the header into
> > JSON.parse(), whereas your construction requires custom parsing.
>
> True, although to be fair, it's the same kind of parsing that's required
> for most other HTTP headers (and it was specifically designed this way
> so that the HTTP header parsing mechanism can be re-used).
>
> > And if I have a JOSE library already on hand (of which there are
> > currently a non-trivial number), I can just toss the whole thing in
> > there and call Verify().
>
> Yep, that's nice, if you have already bought into the whole JWS/JOSE
> stack (which I haven't):
>
> http://manu.sporny.org/2013/sm-vs-jose/
>
> > Also, one thing I like about JWS is that you can make it
> > self-verifying.  That is, you can replace the key ID ("kid") with the
> > actual public key ("jwk"), so the verifier can just go ahead and verify
> > without any pre-provisioning of key IDs.  You can also include metadata
> > like certs.  (Yes, that starts to make the header a little big.
> > Deployment consideration :) )
>
> Yes, you could make it self-verifying that way, but that doesn't seem
> likely in practice? Maybe I'm missing something, but the server still
> needs some piece of information (like a key ID that it knows about) that
> it has access to that says that it trusts the signer in the first place,
> right?
>
> The approach we've taken w/ the Linked Data Signature stuff is to make
> kid/jwk a URL, like this:
>
> https://dev.payswarm.com/i/manu/keys/4
>
> That way, you can just fetch the public key as Linked Data and verify
> the message. Same basic process that you're talking about, but the
> approach is what we're currently using to identify keys for both Linked
> Data Signatures and Signing HTTP Messages.
>
> Here's an example of it in action (look at the Authorization HTTP header):
>
>
> http://opencreds.org/specs/source/identity-credentials/#writing-data-to-the-identity
>
> Also note how the same key is used in the "signature" at the end.
>
> > I wouldn't overestimate the complexity of JWS.  Lines of code is a
> > better metric than lines of spec.  It took me a couple of hours to write
> > a JWS library in Go; signing and verification take ~110 lines, most of
> > which is just algorithm mux/demux.
> > https://github.com/bifurcation/gose/blob/master/jws.go#L139
>
> The signing and verification implementation isn't the hard part w/ the
> JOSE stack, it's everything else you have to pull in. My point isn't
> that "it's possible", it's that "a simpler solution exists".
>
> Out of curiosity, where's the test suite for JOSE (and the
> implementations that pass the various specs)? We don't have an official
> one for the HTTP Signatures stuff yet, either, there's only this (and
> it's not that great):
>
> https://github.com/joyent/node-http-signature/tree/master/test
>
> I'm just trying to get a metric on how much I may be "overestimating the
> complexity of JWS". Maybe I am, but from a read of the specs, I think
> it's safe to say that doing HTTP Signatures requires far less code and
> technologies to be pulled in than the JOSE/JWS stack does. Happy to be
> proven wrong, because I can just drop this Signing HTTP Messages /
> Linked Data Signatures stuff if that turns out to be true. :)
>
> > Finally, if you want to protect headers, you can add a protected header
> > to the above to bind in the header string by reference:
> >
> > ---------------------
> > {
> >   "header": { "kid": "Test", "alg": "RS256" },
> >   "protected": base64({
> >     "header": {
> >       "fields": "(request-target) host date digest content-length",
> >       "sha256": "KCBeV_VF5cEzgjY1cNEAkalw94mJwxtXdz874aRUbRM"
> >   })
> >   "signature": "jgSq...78w"
> > }
> > ---------------------
> >
> > ... where the "sha256" field is the SHA-256 digest of the header string.
>
> Yes, you can protect headers like that, but aren't you just going to end
> up needing the equivalent of the Signing HTTP Messages spec at that
> point to specify how everything is serialized and SHA'd?
>
> > Is this making any more sense?  Basically: Use libraries and scale the
> > complexity to the problem.
>
> Sure, it makes sense. As I said before, I think either approach works.
> I'm just trying to figure out which approach is better. So far, the
> arguments seem to be (warning: broad brush generalizations follow):
>
> JWS is better because it's done and there are multiple implementations
> for it. Just re-use what exists, don't invent something new.
>
> and
>
> JWS is worse because it pulls in a lot of complexity that you don't need
> to solve the particular problem you're trying to solve.
>
> I don't think either approach is going to break the Web or the Internet. :)
>

We certainly agree there :)

Without diving into the details above (holiday laziness setting in), I
actually think your broad brush outline is pretty accurate.  The main place
we differ is the complexity of JWS.

When you say "pull in complexity", what do you mean?  At least at the level
of code, all you need is:
-- A crypto library (which you need for Signing HTTP Messages)
-- A base64 encoder (which you need for Signing HTTP Messages)
-- A JSON parser
-- String concatenation (which you need for Signing HTTP Messages)

The signing process in JWS is wonky (some headers protected and some not;
base64.base64), but not rocket science.  And the key discovery has a lot of
options, but is ultimately not complicated -- you either find a key or you
don't.

And it seems like some of these things could be pinned down by using a
profile of JWS -- e.g., requiring all headers be protected and requiring
that at least one of "jwk" or "kid" be present.  That's pretty much what
I've put in for ACME (minus "kid"), and it's basically the same level of
complexity as a raw signature.

Maybe it would be a fun exercise for your winter vacation to try
implementing JWS to see how hard it really is :)

Happy holidays,
--Richard




>
> -- manu
>
> --
> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
> Founder/CEO - Digital Bazaar, Inc.
> blog: High-Stakes Credentials and Web Login
> http://manu.sporny.org/2014/identity-credentials/
>