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

RE: How to sign several resources (XML and XSL)?

From: John Boyer <jboyer@uwi.com>
Date: Wed, 22 Sep 1999 09:53:30 -0700
To: "Andreas Siglreithmayr" <andreas.siglreithmayr@ixos.de>, "W3c-Ietf-Xmldsig (E-mail)" <w3c-ietf-xmldsig@w3.org>
Message-ID: <NDBBLAOMJKOFPMBCHJOIOEFDCBAA.jboyer@uwi.com>
Hi Andreas,

Please consider the following excerpt from [1].  Other papers available from
the Signed XML workshop are found at [2].  Further information on the
relevance of your question can be found at [3].

[1] http://www.w3.org/DSig/signed-XML99/pp/xfdl.html
[2] http://www.w3.org/DSig/signed-XML99/pp.html
[3] http://www8.org/w8-papers/4d-electronic/xfdl/xfdl.html

Excerpt:

1. Binding Additional Information to a Signature

The textbook formulation [5] for the digital signature algorithm states that
a signature S for a message M is formed by the function Encrypt(hash(M),
PrivateKey), and that verification of signature S is formed by testing the
equality of hash(M) and Decrypt(S, PublicKey). The hash() function must be a
mathematically sound method of measuring change in M.

The well-known shortcoming in this formulation is that security is directly
proportional to the reliability of the method for delivering the public key
to the verification phase. The PKI industry provides solutions to this
problem. There is another problem, equally important, at the opposite end of
the formulation above-- during signing. Consider this question: why is the
signer signing M? The signer affixes a signature only when it is necessary
to give M to another party, the verifier. Since M has a source and a
destination, it is essentially a transaction record. The nature of the
transaction must be important to the parties or there would be no need for a
signature. We expect the digital signature to offer transaction
non-repudiation, but this is only satisfied by non-repudiation of M to the
extent that M completely represents the transaction [1]. The digital
signature authenticates both the message content and the message signer, but
what if the message does not contain sufficient information to capture the
nature of the transaction?

In the electronic forms context, the transaction signer is typically a
person on a client machine whose digital signature implies authorization of
the input as interpreted in the context of the screen layout. The input
values are the answers, and the screen layout includes the questions as well
as the fine print, colors, font information, images, and locations of all
visible information.

XFDL binds the input (data layer) and the screen layout (presentation layer)
by construction. XML application designers could choose to delay binding
until signing time. For example, the user data and stylesheet could be
concatenated into a single message M. This is a bit more problematic than
XFDL solutions since applications must guarantee that the stylesheet bound
to a valid signature is actually the one being used to render the document.

Nonetheless, in applications where a convincing argument can be made for
late binding, an XML element representing a signature would need to allow
for subelements containing additional information beyond what can be
immediately regenerated from the root XML element. Furthermore, it seems
prudent to allow an arbitrary number of these additional elements so that
each can represent a distinct Internet resource. Finally, an encoding
attribute should be added to this subelement to control whether the content
is raw or base 64 encoded [6], the latter of which would allow binding of
non-readable/binary data such as images representing company logos, method
of credit card payment, and so forth.

John Boyer
Software Development Manager
UWI.Com -- The Internet Forms Company


-----Original Message-----
From: w3c-ietf-xmldsig-request@w3.org
[mailto:w3c-ietf-xmldsig-request@w3.org]On Behalf Of Andreas
Siglreithmayr
Sent: Wednesday, September 22, 1999 1:37 AM
To: W3c-Ietf-Xmldsig (E-mail)
Subject: How to sign several resources (XML and XSL)?


	I am a German student of Computer Science and am currently working
as an intern at iXOS Software.

	I would be very grateful if someone could answer a few questions for
me.
	I would like to know how an XML-signature (over several resources)
could be implemented.
	One problem is that XML represents the content of a document and the
presentation of the document is dependent on a style sheet, e.g. an XSL
file.

	I think that if someone signs an XML-document, s/he would also have
to sign the corresponding XSL file.
	If you didn't do this, someone could hide a text by changing the
colour of the text in the XSL so it was the same colour as the background.
	Do you have any idea how this problem should be solved in an
upcoming standard for signatures in XML?

	I would be most grateful if someone could explain it in an example
and what it would look like.

	Would the following algorithm be correct:

	compute the digest of each resource (XSL, XML, etc.)

	merge all digests

	compute the digest of the result

	sign this digest and

	write the result in the <Value>-tag of the <Signature>-tag.

	If this is correct, where would the final digest be written to in
the XML-Signature?

	Thankyou very much for your help.


> -----------------------------------------------------------
> Andreas Siglreithmayr
> Intern
> Innovation
>
> iXOS Software AG
> Technopark Neukeferloh
> Bretonischer Ring 12
> D-85630 Grasbrunn/München
> NEW TELEPHONE NUMBERS!!
> Phone: (+49)-(89)-4629-1136
> Fax: (+49)-(89)-4629-331136
> World Wide Web: http://www.ixos.com/deutschland
> E-Mail: andreas.siglreithmayr@munich.ixos.de
>
>
>
Received on Wednesday, 22 September 1999 12:56:07 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.29 : Thursday, 13 January 2005 12:10:07 GMT