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).
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
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
