I believe Justin was saying you need canonicalization in order to make an
embedded signature work in an interoperable way, since the data structure will
be read, manipulated and serialized out before the signature is verified. I
don’t think he was advocating an embedded signature approach.
If the consensus of this WG was that canonicalization was not a barrier to
interoperability and/or a security risk, I believe JWS would likely embed
signatures and require canonicalization. Instead, the current approach is that
of a separate signature against binary data that in some cases happens to be
parsable JSON.
WRT JSON container, it in my opinion looks like it would be best served as an
alternate serialization of JWS. Instead of the compact JWS form of
b64(metadata) “.” b64(data) “.” b64(signature),
you would likely have
<magic number?> <metadata> 0x1E <fixed width or width-prefixed
signature> 0x1E <data>
- where metadata is defined to be JSON, and data can be whatever your heart
desires.
-DW
> On Jan 29, 2015, at 6:53 AM, Phillip Hallam-Baker <[email protected]>
> wrote:
>
> On Thu, Jan 29, 2015 at 8:14 AM, Justin Richer <[email protected]
> <mailto:[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
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
