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

Re: URI Or Not?

From: John Messing <jmessing@law-on-line.com>
Date: Fri, 17 May 2002 07:16:09 -0700
Message-ID: <004d01c1fdad$653d4bd0$e98e0b3f@laptop>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:21:37 UTC