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 > [email protected] > https://www.ietf.org/mailman/listinfo/acme _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
