W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > July to September 2002

RE: Multiple signatures on multiple files

From: John Boyer <JBoyer@PureEdge.com>
Date: Mon, 29 Jul 2002 12:53:33 -0700
Message-ID: <7874BFCCD289A645B5CE3935769F0B523289F1@tigger.PureEdge.com>
To: "David Wall" <dwall@Yozons.com>, "Christian Geuer-Pollmann" <geuer-pollmann@nue.et-inf.uni-siegen.de>, <w3c-ietf-xmldsig@w3.org>

Hi David,

I've given this a fair bit of thought in the past, and the group discussions of this issue included a number of members from the legal community.

The consensus is that there are no problems with our approach.

I do understand your concern completely, that you are signing a bag of bits that is 'once removed' from the 'actual data'.  However, there are several points to consider even if we remove the two-step that XML Signature performs:

1) A digital signature itself is generated over a hash of the data.  The hash is a 'lossy' technique that boils every message down to a constant sized 'fingerprint'.  The legal community already accepts as technologically sound the application of signature techniques over some metadata (a fingerprint or hash) rather than over the actual data itself.

2) Typically, the data being hashed and signed is already removed several steps from the 'actual data' that represents what the user saw, heard or otherwised sensed that comprised the actual agreement.  For example, consider a web transaction that includes an image showing an object the signer wants to purchase or the company logo of the brand of object the signer believes he is purchasing.  The signer views a 24-bit color bitmap of the image, which is the 'actual data'.  But the 'signed data' is a set of XML tags between which appears the base 64 encoding of a JPeg compressed version of the aforementioned bitmap.

Notice, in particular, that the JPeg compression is a 'lossy' technique.  Despite these levels of indirection, we find no problem with the approach because there is a well-defined and straightforward set of transformations that allow validation of the actual data against the signed data.

3) Even the very idea of signing the ASCII codes for the characters in an English language sentence implies indirection.  Essentially, "what you see is what you sign", but what we sign is an index into a font map that is not even stored in the document.  But, as with JPeg images and base 64 encoding, we accept these bags of bits as being the proper representative of what we really want to sign, which is a bunch of dots on the screen.

And now for the purely philosophical:  Even the bunches of dots are only useful because, at the resolution typically used on our computing platforms, the dots meld together to form the symbols that having meaning to us.

So, the precedent for well-defined indirection has been set long before XML Signature came to the scene.

John Boyer, Ph.D.
Senior Product Architect
PureEdge Solutions Inc.

-----Original Message-----
From: David Wall [mailto:dwall@Yozons.com]
Sent: Monday, July 29, 2002 11:54 AM
To: Christian Geuer-Pollmann; w3c-ietf-xmldsig@w3.org
Subject: Re: Multiple signatures on multiple files

> Signing "real data", i.e. signing the message directly is not such a good
idea as it opens the algorithm to some attacks, especially if you use plain
RSA (which would be a very bad idea).

True, but a lot of typical signing includes a hash (RSA/DSA with SHA1), but
the SHA1 works against the actual data being signed (in both digital
signature and legal sense).  In XML Signature, there's a two step process of
doing an SHA1 on the actual data, and then digital signing (hash the hash
and encrypt with the private key), so the digital signature is "signing" a
hash, not the original data.  Anyway, I believe it's sound technically, just
wondered if there's anything "odd" from a legal standpoint since the
signature is once removed from the data being signed.

Received on Monday, 29 July 2002 15:54:06 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:10:10 UTC