On Thu, Jan 29, 2015 at 8:14 AM, Justin Richer <[email protected]> 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.
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
