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