Re: URI Or Not?

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

Yes, this is possible.  In fact, one can go further because if one is in a
closed system where variation in signatures is well-restricted, either end
can even go as far as pre-setting the bytes prior to and after the digest(s)
in SignedInfo, thus forgetting about all that XML processing not directly
related to cryptographic algorithms.  Then the major performance time
(beyond the cryptography) is the extracting of the digest bytes, the
signature value, and whatever KeyInfo is necessary.  Ultimately, if you know
the digest, the signature value, the signed bytes, and the public
verifcation key, that's all you need to know to optimize the processing.
XML Signature provides a very flexible and powerful packaging format which,
in all its glory can be a performance issue, but that doesn't mean specs
built upon XML Signature, can't choose to restrict that functionality to
achieve the performance goals.  In fact, the ability to include and subclass
XML Schemas lends itself to this practice.

From a Toolkit perspective, the important thing is to ensure the Toolkit
provides the higher level functionality for general XML Signature
processing, but also provides low-level functionality such as
XmlSignature.getDigest() and XmlSignature.getSignatureValue() for those
applications which operate in well-defined environments.

Regards, Ed

----- Original Message -----
From: "John Messing" <jmessing@law-on-line.com>
To: <w3c-ietf-xmldsig@w3.org>
Sent: Friday, May 17, 2002 10:16 AM
Subject: Re: URI Or Not?


> 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:48:31 UTC