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

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

On Thu, Jan 29, 2015 at 4:28 PM, Richer, Justin P. <[e-mail]>
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 :-)