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

[Phillip Hallam-Baker <[e-mail]>]

On Thu, Jan 29, 2015 at 8:14 AM, Justin Richer <[e-mail]> 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.