- 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>
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 UTC