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

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

On Thu, Jan 29, 2015 at 2:40 PM, Daniel Kahn Gillmor <[e-mail]>
wrote:

> On Thu 2015-01-29 08:53:58 -0500, Phillip Hallam-Baker wrote:
> > 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.
>
> 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).
>

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.




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

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


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


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

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



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

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



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