On Wed, Jan 28, 2015 at 5:43 PM, Nico Williams <[email protected]>
wrote:
> On Wed, Jan 28, 2015 at 01:14:58PM -0500, Phillip Hallam-Baker wrote:
> > <JSON-BLOB> [Separator] <content-blob>
>
> I'll bite.
>
> Why not:
>
> <metadata JSON> <separator> <signature> <content>
>
> > Advantages:
> >
> > * Can read the metadata for a file etc with a plain ASCII editor or
> command
> > line tools like cat, more, etc.
> >
> > * Avoids the need to BASE64 armor the content. So if the content is JSON
> or
> > other ASCII/Unicode text it remains readable in an ASCII/Unicode editor.
>
> Why even have to base64-encode the signature?
>
> > * Can add signatures, digests and other metadata items to content in a
> > simple regular fashion.
>
> Ah. Hmm, right! It'd have ot be:
>
> <metadata JSON> <separator> <signature> <content> [<extra signatures>]
>
> or
>
> <metadata JSON> <separator> <content> [<signatures>]
>
> or as you suggest, put the [base64-encoded] signatures in the metadata.
Yep, that is the reason for doing it the way proposed. It is really useful
and necessary to have multiple signatures on the same content. This allows
for multiple algorithms, multiple signers, etc. Or just a signature and a
digest.
> > * It is a historical artifact and content metadata headers are mixed in
> > with protocol metadata headers without rhyme or reason.
> >
> > * It is not JSON and JSON is the spec we are now converging on for this
> > type of work. It has all the expressive capabilities of XML and ASM.1
> > without the insanities and stupid. It is as easy to read and write as
> > RFC822 but without the limitations.
>
> Meh. It's just one of many suitable encodings. Pick one, any one.
They seem to have picked JSON. Or S-expressions with curly braces if you
like to look at them that way...
> > JSON sequence specifies that "A JSON text sequence consists of any number
> > of JSON texts, all encoded in UTF-8, each prefixed by an ASCII Record
> > Separator (0x1E), and each ending with an ASCII Line Feed character
> (0x1A)"
> >
> > This is not ideal for JSON Container. We would prefer that the character
> > which is illegal in a JSON document be the one that is the separator
> > between the header and content.
>
> Just make it:
>
> RS JSON-blob LF FS content
>
> (That would be as close as this could get to being a JSON text
> sequence while also being sufficiently different.)
Works for me. If we are using RS, might as well use FS.
>
> > Applying this in a Web Service is very simple, our messages now have the
> > form:
> >
> > POST / HTTP/1.1
> > Host: example.com
> > Content-Type: application/json-container
> > Content-Length: 666
> >
> > { "Signature" : "wefwkjefkljwehfjklwhejkflh" }
> >
> > <0x1E>{ "Service-Type" : "acme.ws",
> > "Transaction-ID" : "2h23roih23oih23orh",
> > "Register" : { ....<web service parameters here> ... } }
>
> OK, but why not put all of this into the headers anyways?
Well that is what I suggested in my Content-Signature work and that is
exactly how my code works today. But folk proposed introducing the
signature in the HTTP content segment and that forced me to think about
which approach is better.
I think I can make a good architectural argument for the JSON Container
approach and besides which it is really useful at the file system level.
Separating out protocol data from content-metadata is long overdue.
>
> > Notice how we have just developed a format that allows us to sign a
> > complete code distribution including content data very easily. This is
> > obviously out of scope for ACME but the fact that an approach transfers
> so
> > neatly to a completely different problem suggests that it is the right
> > track.
>
> Wasn't JOSE about this sort of thing?
>
Sort of. That might be where we eventually do the work. But the
requirements would be ACME in the first instance and the constraints from
JSON. I would see JOSE as being something we just plop in and should work
(or else they have some splainin' to do.
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
