- From: John Messing <jmessing@law-on-line.com>
- Date: Fri, 17 May 2002 07:16:09 -0700
- To: <w3c-ietf-xmldsig@w3.org>
I find this thread to be very useful but it raises questions to me about the ultimate usefulness of xml dsig for signing objects. Because the spec is based upon signing references that are described in xml, even if no other xml is being signed and no other transforms may be necessary, the method requires cannonicalization, as Manoj's example demonstrates, which according to the interoperability results, degrades performance. (Even at the best reported result from John Boyer of .5 second to sign, this seems acceptable only for atomic transactions and probably will not be acceptable for high traffic server transactions). My concern is that, coupled with the inferior performance of asymmetric signature methods, the combination of asymmetric signatures with cannonicalization may prevent scalable solutions where for example a server needs to sign high traffic batched transactions. While the use of HMACS could possibly help to restore performance, they are generally not recommended for non-repudiation purposes. Take for example a simple application that generates a detached RSA signature (of a binary object, not its xml dsig reference), a SHA-1 message digest, and a base64 representation of the object. It should be relatively easy and efficient to generate an envelope in xml to take these three objects and transport them from point A, where the signature was generated, to point B where a holder of the public key will verify the signature after reversing the base64 encoding. (One could even theoretically avoid signing the entire package of objects by using an SSL connection). But as I understand the spec, if an envelope is created in xml to perform the transport, it will not be considered to be compliant with xml dsig unless it uses <signed info/>, even though the application will more likely perform its task more efficiently than it would than if it were cast in dsig because cannonicalization has been eliminated. Alternatively, where the xml dsig syntax is being generated at a server using for example a scripting language, could a cannonicalization transform be avoided by making sure that the application that generates the script introduces no white spaces or carriage returns and line feeds, so that the need for the cannonical transform is eliminated to begin with? Have I stated the matters properly? If so, should there be some exception in the spec to allow for this type of transport as permissible, even as a recognized exception to the methods otherwise set out in the spec? ----- Original Message ----- From: "Christian Geuer-Pollmann" <geuer-pollmann@nue.et-inf.uni-siegen.de> To: <tony@vordel.com>; <w3c-ietf-xmldsig@w3.org> Sent: Friday, May 17, 2002 3:31 AM Subject: Re: URI Or Not? > > The value of the URI attribute contained in the Reference element in > > Manoj's example is "logo-text.gif". Should this not be prepended with > > "file://" to give URI="file://logo-text.gif" to make it a valid URI? > > No, no need to. > > file://logo-text.gif is an ABSOLUTE URL. > > logo-text.gif is a RELATIVE URL and refers to the same directory in which > the file resides which carries the XML Signature. For instance, if the > signature file is in > > http://www.vordel.com/~tony/mySignature.xml > > , the URI="logo-text.gif" refers to the entity (file) > > http://www.vordel.com/~tony/logo-text.gif > > . If the signature is in a file on URL > > file://C|/My Documents/Tony/mySignature.xml > > , the relative URI refers to > > file://C|/My Documents/Tony/logo-text.gif > > . The advantage of a relative URI for a detached signature is that you can > move around signature and signed contents from your local file system to a > web server or whatever, the signature remains valid (as long as the target > system supports the concept of what-is-a-directory and > how-to-resolve-relative-URLs. > > > Christian > > >
Received on Friday, 17 May 2002 10:23:14 UTC