Subject: [Acme] Signed JSON document / Json Content Metaheader / JSON Container

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 28 Jan 2015 13:14:58 -0500

All,

I would like to propose a spec similar to the JSON log file spec but with
the purpose of being a container for JSON signatures. The immediate
application for this might be for ACME or other JSON/Rest Web services.

The elevator pitch for the idea is that a JSON Container would be a JSON
Metadata blob with the content being described appended to the end in a way
that makes the separation between content and metadata simple and
unambiguous.

<JSON-BLOB> [Separator] <content-blob>

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.

* Can add signatures, digests and other metadata items to content in a
simple regular fashion.

* Content and metadata can be transported as a simple regular blob that is
fully abstracted from and independent of the transport and without the need
for canonicalization, XPath or other complications.

Right now, the IETF spec for describing content metadata is based on
RFC822. And by 'based on', I mean that it is a find the needle in the RFC
haystack approach. RFC822 style content headers as currently used have
several disadvantages:

* It is a flat structure, headers can have attributes but trying to add
more structure is painful.

* 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.

The spec itself would be simple, its
basically draft-ietf-json-text-sequence applied to a sequence of one json
object and one content blob.

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.

All indexes used in the metadata header are calculated from the Record
Separator byte, the first byte following being byte 0 and so on.

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> ... } }

Where <0x1E> is the record separator character.

The scope of the signature is the content, the whole content, AND NOTHING
BUT THE CONTENT. Signing headers is a mugs game. Put all the information
that matters into one blob and sign the blob. Do not present developers
with an IKEA self-assembly job.

So to prevent protocol substitution attacks, the service identifier and the
method name wrap the method parameters. In a response, the service
identifier, response code and transaction ID wrap the response data for the
same reason.

Applying the scheme to stored data in a file system is a little different.
First we have to develop a file extension convention:

file.jpg  becomes file.jpg.jsonc

Many jsonc aware applications will have to share data with applications
that are not aware. So we need the option of storing metadata in a separate
file when that is convenient:

The metadata for file.jpg is stored in file.jsonm

In some circumstances we might want to keep the metadata for all the files
in a directory or tree in one file, a metadata container. This could be
jsonmc.jsonmc appearing in either the directory a file is in or one of the
directories above it.

A metadata container would be a JSON container and begin with the usual
metadata header for that file followed by a JSON sequence of entries per
file. If this contains a signature, the file entries can just be digests.

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.

---

From: Anders Rundgren <[email-masked]>
Date: Wed, 28 Jan 2015 22:04:38 +0100

Hi Lists,

As expected the flood of various JSON clear-text signature schemes would come sooner rather than later :-)

Which one is best?  Well that would be comparing oranges with apples and personally I prefer strawberries!

Cheers,
Anders

On 2015-01-28 19:14, Phillip Hallam-Baker wrote:
> All,
>
> I would like to propose a spec similar to the JSON log file spec but with the purpose of being a container for JSON signatures. The immediate application for this might be for ACME or other JSON/Rest Web services.
>
> The elevator pitch for the idea is that a JSON Container would be a JSON Metadata blob with the content being described appended to the end in a way that makes the separation between content and metadata simple and unambiguous.
>
> * 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.
>
> * Can add signatures, digests and other metadata items to content in a simple regular fashion.
>
> * Content and metadata can be transported as a simple regular blob that is fully abstracted from and independent of the transport and without the need for canonicalization, XPath or other complications.
>
>
> Right now, the IETF spec for describing content metadata is based on RFC822. And by 'based on', I mean that it is a find the needle in the RFC haystack approach. RFC822 style content headers as currently used have several disadvantages:
>
> * It is a flat structure, headers can have attributes but trying to add more structure is painful.
>
> * 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.
>
>
> The spec itself would be simple, its basically draft-ietf-json-text-sequence applied to a sequence of one json object and one content blob.
>
> 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.
>
> All indexes used in the metadata header are calculated from the Record Separator byte, the first byte following being byte 0 and so on.
>
>
> Applying this in a Web Service is very simple, our messages now have the form:
>
> POST / HTTP/1.1
> Host: example.com <http://example.com>
> <0x1E>{ "Service-Type" : "acme.ws <http://acme.ws>",
> The scope of the signature is the content, the whole content, AND NOTHING BUT THE CONTENT. Signing headers is a mugs game. Put all the information that matters into one blob and sign the blob. Do not present developers with an IKEA self-assembly job.
>
> So to prevent protocol substitution attacks, the service identifier and the method name wrap the method parameters. In a response, the service identifier, response code and transaction ID wrap the response data for the same reason.
>
>
> Applying the scheme to stored data in a file system is a little different. First we have to develop a file extension convention:
>
> Many jsonc aware applications will have to share data with applications that are not aware. So we need the option of storing metadata in a separate file when that is convenient:
>
> In some circumstances we might want to keep the metadata for all the files in a directory or tree in one file, a metadata container. This could be jsonmc.jsonmc appearing in either the directory a file is in or one of the directories above it.
>
> A metadata container would be a JSON container and begin with the usual metadata header for that file followed by a JSON sequence of entries per file. If this contains a signature, the file entries can just be digests.
>
>
> 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.
>
>
>
>
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>

---

From: Nico Williams <[email-masked]>
Date: Wed, 28 Jan 2015 16:43:49 -0600

> <JSON-BLOB> [Separator] <content-blob>

I'll bite.

Why not:

<metadata JSON> <separator> <signature> <content>

> 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

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.

> more structure is painful.

Flat structure has its advantages.

A while back I posted a list of kinds of encodings, asking if there was
any I'd missed.  I did miss one important one myself: Lustre's RPC.

Lustre's RPC doesn't support seqeuences-within-sequences-within-
sequences like all the others do.  It's more like a single top-level
sequence of fixed- and variable-length things, where the fixed-length
ones contain C-like structs (with all-fixed-length fields), and the
variable-length ones containing only things like filenames.  (Bulk data
is sent separately, via RDMA-like protocols.)

The main advantage to this is that all the critical length checks go in
one place in the code.

Whereas a JSON blob is not flat.  It could be arbitrarily deep.

> RFC822 but without the limitations.

Meh.  It's just one of many suitable encodings.  Pick one, any one.

> object and one content blob.

Pretty much, yes (but it's not the same: the blob would not be a JSON
blob).

> 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.)

>    "Register" : { ....<web service parameters here> ... } }

OK, but why not put all of this into the headers anyways?

> neatly to a completely different problem suggests that it is the right

Wasn't JOSE about this sort of thing?

Nico
--

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 28 Jan 2015 18:11:46 -0500

> 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.

> 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...

> sequence while also being sufficiently different.)

Works for me. If we are using RS, might as well use FS.

> 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.

> 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.

---

From: Nico Williams <[email-masked]>
Date: Wed, 28 Jan 2015 17:20:06 -0600

> which approach is better.

Your approach looks like a Transfer-Encoding to me.  If that's what it
looks like, and that's what it walks like, [and that's what we want,]
then that's what it should be.

> approach and besides which it is really useful at the file system level.

You want the contents of the object to include the signature??

I mean, I've wanted filesystems to expose some internal metadata (e.g.,
a Merkle hash tree root hash for a file's content, with those parameters
needed to reconstruct the same hash from just the contents, namely, the
shape of the tree and the size of each non-tail block of contents).  But
making this part of the contents instead of the metadata strikes me as
rather problematic.

> Separating out protocol data from content-metadata is long overdue.

Maybe, but I do want POSIX to continue not commingling contents and
metadata.

> (or else they have some splainin' to do.

I meant: why not use whatever JOSE delivered?

Nico
--

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 28 Jan 2015 19:50:29 -0500

> then that's what it should be.

Umm, I designed the Chunked transfer encoding. A TE gives the length of
blobs. This is not a TE.

> You want the contents of the object to include the signature??

No, I want the option of doing drag and drop on the file plus metadata blob
in a fully interoperable fashion. So the contents are still the contents.
But they are prefixed by the metadata.

> making this part of the contents instead of the metadata strikes me as

It isn't making it part of the contents. Metadata is still metadata.

Trying to get the file system to support additional semantics is a losing
proposition. And even if they are supported they won't be standard across
all the platforms.

> Maybe, but I do want POSIX to continue not commingling contents and

I want POSIX to curl up in the corner and die.

Co-mingling the contents and metadata are an inevitable consequence of
considering files to just be a stream of bits. inside the container is the
only place that metadata can go.

UNIX has had horrid kludges for putting metadata into the content since the
start. Thats what magic numbers are.

> I meant: why not use whatever JOSE delivered?

Base64 encoding the content so as to be able to work out the boundaries.
Blech.

---

From: Nico Williams <[email-masked]>
Date: Wed, 28 Jan 2015 18:54:01 -0600

> Umm, I designed the Chunked transfer encoding. A TE gives the length of

So it's a new MIME type of signed data?

OK.

> Base64 encoding the content so as to be able to work out the boundaries.

That's what I thought.  Base64 avoidance for bulk sounds good to me.

Nico
--

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 28 Jan 2015 20:02:01 -0500

> So it's a new MIME type of signed data?

A  new MIME type of JSON wrapped data similar to the rfc822 type.

The content could be encrypted for example or just be the metadata.

---

From: "Manger, James" <[email-masked]>
Date: Thu, 29 Jan 2015 13:51:13 +1100

A signed JAR file meets some of these requirements.
Metadata and signatures are in extra files in the ZIP archive: META-INF/MANIFEST.MF, META-INF/MYKEY.SF, META-INF/MYKEY.RSA.
Content is the other files in the archive.
It is not JSON of course, and the signature & certs are packaged in ASN.1, but it is a useful comparison. It avoids BASE64 on the content; can adds signatures, digests, and other metadata; can transport content and metadata as a regular blob (*.jar file); can sign complete code distributions.

--
James Manger

From: Acme [mailto:[email-masked]] On Behalf Of Phillip Hallam-Baker
Sent: Thursday, 29 January 2015 5:15 AM
To: JSON WG; [email-masked]
Subject: [Acme] Signed JSON document / Json Content Metaheader / JSON Container

All,

Advantages:

POST / HTTP/1.1
Host: example.com<http://example.com>
Content-Type: application/json-container
Content-Length: 666

<0x1E>{ "Service-Type" : "acme.ws<http://acme.ws>",
   "Transaction-ID" : "2h23roih23oih23orh",
   "Register" : { ....<web service parameters here> ... } }

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 28 Jan 2015 23:03:05 -0500

On Wed, Jan 28, 2015 at 9:57 PM, Nat Sakimura <[email-masked]> wrote:

> On a side note: if such a spec is to be defined here, IMHO, it should use
> the algorithms and probably header parameters specified by JWA, etc. It
> should limit the scope to payload processing and expression of the entire
> thing in JSON Log like format, and leave the rest to JOSE.
>

Absolutely. In fact that is why I am not raising it in JOSE as that just
provides the format for the main crypto attributes.

> On Thu Jan 29 2015 at 11:51:24 Manger, James <
> [email-masked]> wrote:
>
>> Metadata and signatures are in extra files in the ZIP archive:
>> META-INF/MANIFEST.MF, META-INF/MYKEY.SF, META-INF/MYKEY.RSA.
>>
>> It is not JSON of course, and the signature & certs are packaged in
>> ASN.1, but it is a useful comparison. It avoids BASE64 on the content; can
>> adds signatures, digests, and other metadata; can transport content and
>> metadata as a regular blob (*.jar file); can sign complete code
>> distributions.
>>
>>
>>
I have used signed jar files. But Sun rather poisoned the well there by
suing Microsoft over control of Java followed up by further lawsuits from
Oracle.

I can't imagine anyone is going to accept Jar or anything involving
assinine.1 as a wire format for packaging. Those days are long past. The
way you get coherence is to pick one encoding and stick to it. JSON seems
to have been the one we picked. It has all the functionality offered by the
alternatives and none of the drawbacks.

---

From: Fraser Tweedale <[email-masked]>
Date: Thu, 29 Jan 2015 14:25:09 +1000

> alternatives and none of the drawbacks.

There are ∞ valid ways to serialise a JSON object.  If a JSON object
is signed over, it must be canonicalised, or signed over and
transported in serialised form.  JOSE takes the latter approach
(base64url-encoded serialised JSON object, inside a JSON object),
while JWK thumbprint draft uses canonicalisation.  ASN.1 encodings
and deterministic binary serialisations can avoid the need for these
sorts of hacks.

I agree the JSON ship has sailed, but there *are* drawbacks.

Regards,
Fraser

---

From: Anders Rundgren <[email-masked]>
Date: Thu, 29 Jan 2015 06:38:45 +0100

On 2015-01-29 05:25, Fraser Tweedale wrote:
Hi Fraser,

 > I agree the JSON ship has sailed, but there *are* drawbacks.

The JSON ship may have sailed but it is actually more like a dinghy when
look closer making a turn or two fairly realistic.

Using predictable serialization which is anything but rocket-science,
"canonicalization" can [often] be reduced to "stringify":

https://openkeystore.googlecode.com/svn/resources/trunk/docs/jcs.html

https://code.google.com/p/openkeystore/source/browse/python/trunk/src/org/webpki/json
https://code.google.com/p/openkeystore/source/browse/resources/trunk/docs/JCSDemo.cs

Anders

---

From: Fraser Tweedale <[email-masked]>
Date: Thu, 29 Jan 2015 16:59:04 +1000

> "canonicalization" can [often] be reduced to "stringify":
This means that you either:

    a) have a JSON library that serialises objects in precisely the
       manner required, or affords users the degree of control needed
       to achieve it, or
    b) must write the serialisation function yourself

Although b) is not rocket-science, the format is hostile to code
reuse.  JOSE made a different tradeoff - you can use any JSON
library but the format is more complex.  One drawback is traded off
against another.

JSON has benefits compared with ASN.1, but using it presents you
with an unavoidable choice between significant drawbacks.  This fact
ought not be glibly ignored.

Regards,
Fraser

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 29 Jan 2015 08:53:58 -0500

On Thu, Jan 29, 2015 at 8:14 AM, Justin Richer <[email-masked]> wrote:

> Relying on side-effects of a handful of contemporary implementations is
> dangerous at best and absolutely foolhardy at worst, especially when it
> comes to security systems. You *need* to have a formal canonicalization,
> normalization, or serialization in order for these things to work in
> practice.
>
> Otherwise, you're betting on luck, and that's just daft.
>

-1E200

Canonicalization is the stupidest idea in computer security. It is never
ever necessary and never ever implemented reliably.

A digital signature signs a sequence of bits. So if you ever want to check
a signature again, make sure you keep hold of your original sequence of
bits. Simple!

I see people say that canonicalization is 'essential' in every discussion
of signatures. What I have never seen is an example of something that is a
reasonable thing to do that goes wrong if you don't have C15N.

And by reasonable, I do not mean 'take a cert, store it in X.500 directory,
reassemble'. DER encoding is the stupidest stupid of all the steaming piles
of stupid in ASN.1. BER meets the needs of X.509 just as well, as was
proved by the fact that the Web ran quite happily on BER encoded certs
until some spoilsport let on what we had been doing.

The reason I am proposing JSON Container is precisely to avoid the need for
canonicalization. That does not work in XML Dig sig and it won't work for
JSON.

My proposal has three parts:

1) A blob of data where the only requirement is that it must be a valid
JSON encoding. Changing this is permitted. Want to add another signature,
go ahead! So not only are syntactic differences allowed, semantic changes
are allowed as well.

2) A separator marker to unambiguously define the end of (1) and the start
of (3)

3) The sequence of bits that was signed.

A signature in (1) cannot refer to any part of (1), it can only reference
(3) and is by default the whole of (3) but could be a well defined range
inside (3) instead.

That is it, no JSON canonicalization or unique serialization required. This
is a proposal for wrapping arbitrary content data with a wrapper that
contains JSON metadata which might include signatures. There is no reason
for either the signature or the data to be in a canonical form.

If you want to have signed metadata, you would need to first wrap the
content with a JSON Container with the metadata and then wrap that with a
second container with the signature.

---

From: Anders Rundgren <[email-masked]>
Date: Thu, 29 Jan 2015 15:26:04 +0100

> normalization, or serialization in order for these things to work in

You are right: JCS isn't guaranteed to run on any JSON implementation.

However, JCS doesn't rely on side-effects, it has a formal normalization
scheme (the description may be crap but there is one at least), which is
explicitly implemented in two (yes, only two) reference implementations.

Then I have with the help of available documentation and communication
with the authors, verified that two "commercial" JSON implementations
also can support "predictive serialization" which BTW is a requested
item by the general JSON community for the simple reason that humans
(unlike computers) find it somewhat odd that if you define properties
A,B,C they come out as A,C,B.

The only (known NB) "fly in the soup" is that floating-point serialization
usually requires some specific measures to work as mandated by the JCS
normalization scheme.  If this is a show-stopper and can't be corrected,
your best option is using JWS of course.  The idea was never ever to
"compete" but to "complement".  I have adjusted the JCS during the voyage
so that it nowadays reuses JOSE algorithms, curves, public key objects, and
signature blob format.  "Crypto compatible".

> Otherwise, you're betting on luck, and that's just daft.

Since I don't consider myself a gambler, I guess I have to settle on "daft" then :-)

Anders

>
>    -- Justin
>
> On 1/29/2015 12:38 AM, Anders Rundgren wrote:
>> jose mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/jose
>

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 29 Jan 2015 14:40:26 -0500

> reasonable thing to do that goes wrong if you don't have C15N.

RFC 1847 (Security Multiparts for MIME) [0] recommended this "keep the
original sequence of bits intact" variant way back in 1995:

>>    The entire contents of the multipart/signed container must be treated
>>    as opaque while it is in transit from an originator to a recipient.

But some implementations still get this wrong, and it breaks some signed
messages today, depending on how those messages are handled in transit.
(this is about RFC822 header canonicalization, fwiw, not JSON
canonicalization, but the point is the same).

For example, In 2004 (probably earlier), it was observed that python
e-mail parser failed to "keep the original sequence of bits intact" [1],
and the bug is still not fixed today, afaict.

We're talking about nearly 20 years of failing to do this "easy"
approach.  

Taking the other approach, OpenPGP signatures of textual data use a
canonicalized document format (specifying <CR><LF> line-endings,
ignoring whitespace at the end of lines, back in 1998) [2], and that
seems to have actually worked out OK in terms of interop, though i've
seen some (quickly-fixed) errors pop up over the years.

People want to investigate and parse and display the content they're
working with, even if there is a signature on it.  It's very tempting
for implementors to treat the parsed form as the sole internal data, and
not to keep around the other binary blob.  Having a well-documented
canonicalization procedure makes that easier.

i'm not saying that canonicalization is necessarily the right solution
here, but it's not like the "just keep your bits intact" proposal is
particularly robust either.

       --dkg

[0] https://tools.ietf.org/html/rfc1847#page-4
[1] http://bugs.python.org/issue968430
[2] https://tools.ietf.org/html/rfc2440#section-7.1

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 29 Jan 2015 18:18:37 -0500

> canonicalization, but the point is the same).

HTTP is defined as a 8-bit clean. If the content does not pass through with
every bit intact then abort and retry.

Now certainly, if you want to transfer huge gobs of data then you probably
want to use a different transfer encoding that divides the content into
chunks with separate error checks.

> and the bug is still not fixed today, afaict.

Which is why I would only use HTTP which does not have that issue.

> We're talking about nearly 20 years of failing to do this "easy"

Only for SMTP. HTTP has had 20 glorious years of success in that regard.

> seen some (quickly-fixed) errors pop up over the years.

Only if you don't want to use MIME messages in which case weeping and
gnashing of teeth awaits one.

> canonicalization procedure makes that easier.

And deliberately not using a canonicalization scheme makes that misguided
approach impossible.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 29 Jan 2015 19:47:52 -0500

On Thu, Jan 29, 2015 at 4:28 PM, Richer, Justin P. <[email-masked]>
wrote:

>  I think you missed my point. I wasn't saying that I *liked*
> canonicalization and normalization but rather that you *need* either it or
> something *equivalent* in order to get the same set of bits out of either
> end. Like you, what I was saying was that you need *something* that makes
> your bit stream stable.
>

Sure but that does not need to be in the signature format. I would prefer
to simply tell people that they have to get this package from A to B with
absolutely no modifications or it won't work.

> I'm actually in favor of the JOSE approach, which is exactly to keep the
> original bits around by protecting them with Base64url over the network so
> that they don't get munched. As an implementor, this is fantastic, as it
> makes my code much simpler in terms of both generation and consumption.
>

I don't like that for the general case though as the main advantage of JSON
is that it is human readable and I can't translate back and forth between
Base64 in my head any more.

> I have the JSON objects where I need them and the raw streams where I need
> them, and I can easily keep them separated with a reasonable assumption
> about them not being confused with each other. For heaven's sake, don't do
> canonicalization. But at the same time, don't assume that a JSON blob is
> going to be kept pristine as a string by any JSON-processing system.
>

That is one of the reasons for insisting on a sharp division between 'that
which is signed' and 'the JSON bit'.

> So we're actually in violent agreement on this point. In my view, JOSE's
> approach of keeping the original bits around is the desirable one by far.
>

I thought you might intend something like that but its not what I think you
said and it gave me an opportunity to use the phrase steaming piles of
stupid :-)