[dboreham]

I believe the problem being addressed is where the payload may be transcoded in flight or otherwise not delivered in exactly the same form. Put another way: the signature validates the payload, however it may end up being represented to the validator on delivery. It isn't simply a transport integrity measure.

[hnarn]

I might be missing the point here, but isn't the whole idea of signing a message that it should not be possible to "transcode the message in flight"? If you even allow the message to be "not delivered in exactly the same form" in the first place, you're introducing an attack vector completely without reason, because what you instead could do is let the payload be strongly signed and unchanged, and then have differing parsing rules at the end.

[koolba]

Yep and it’s even worse because the signing and encryption involves XML transforms to canonicalize the source prior to verifying them. So you force the recipient to not only validate a potentially transformed message, but they have to transform it again too!

It’s the perfect intersection of precarious and deranged.

[whatshisface]

You sign your letter and seal it in an envelope. I put your envelope into a cardboard box and give it to your friend. Your friend refuses to open your letter because you did not sign my box.

[jeltz]

No, this is more like your friend refusing to trust the contents of the letter after the mailman cut the letter into small pieces and glued them back together.

[hnick]

I think that would be more analogous to receiving a message, parsing it, then realising the payload is another signed message, and then validating that.

Depending on the situation, signing the container might not even be necessary, much like a zip file without a password that only contains encrypted contents anyway.

[syrrim]

Usually, signing the whole damn thing is too computationally expensive, so you sign a hash instead.