RE: From OASIS digital signatures services TC: request of comments

Wrt issue 1, an XML Signature <Reference> element does, as you say, only
sign the result of the applying the transforms to the referenced data.
Indeed, it is possible that one could change only the referenced data, only
the transforms, or both the referenced data and transforms, and achieve the
same final result.  This is fine if the only material data that needs to be
signed is the resultant and I can imagine legitimate scenarios where the
referenced data and transforms are changed with care taken not to alter the
signed result.

If it is important for your protocol to protect the integrity of the
referenced data and/or the transforming code, then your XML Signature
processing needs to mandate that, probably using additional
SignedInfo/Reference constructs.

In issue 2, you need to ensure that all data relevant to making the
signature useful is indeed signed.  It makes no sense for example to sign an
HTML page but not its linked images, if those images are essential to the
reason the signature is being implied.  XML Signature provides the basis for
signing multiple documents (in whole or in part) but cannot define for
specific application scenarios, what to sign.  It is up to protocol and
application designers to subclass XML Signature (eg. have something
conformant to the XML Signature schema but more constrained) according to
the specific needs of that protocol or application.

For issue 2, you could sign both the raw data and the transformed result,
AND have your protocol define the exact requirements in relating the two.
Verifying that those exact requirements have been met is beyond the scope,
intentionally, of XML Signature; such requirements belong in the utilizing
protocol specifications.

At one point I recall, the XML Signature group did discuss the topic of,
what I would call, "signing the user's experience".  What a user sees may be
dependent not only on the raw data or XML tranforms, but also the transform
engine, the browser version, the existence of script engines, the fonts
available on the machine, the pixel resolution of the monitor, ad infintum.
Generally, there is no practical way to have perfect mathematical certainty
connecting the a user's experience with application data.  However, from a
legal standpoint, such perfect certainty is not necessary.  For more detail
on this matter, may I highly recommend the "Legal Considerations" chapter in
the new book "Web Services Security" (see my website
"http://www.xmlsec.com/" or
"http://www.amazon.com/exec/obidos/ASIN/0072224711/vordel-20/no-sim/104-3423
601-8567918" for details).

Regards, Ed

----------------------------------------------------------------------------
-------------------------------------------
Ed Simon
<edsimon@xmlsec.com>
(613) 726-9645
XMLsec Inc.

Interested in XML Security Training and Consulting services?  Visit
www.xmlsec.com.
========================================================


Message-Id: <3.0.1.32.20030411174205.01100810@popserver.ac.upc.es>
Date: Fri, 11 Apr 2003 17:42:05 +0200
To: w3c-ietf-xmldsig@w3.org
From: Juan Carlos Cruellas <cruellas@ac.upc.es>
Cc: dss@lists.oasis-open.org
Subject: From OASIS digital signatures services TC: request of comments


Dear all,

During the dicussions that take place within
 the OASIS Digital Signature Services Technical Committee, which
is currently working in the specification of Web Services for producing and
veriffying digital signatures, two issues have been raised on which the
aforementioned TC would like to know your opinions and views.

These two issues have been well summarized by
one of the members in the group as follows:

-------------------->

1. Securing Transform Chain -

Normally, the relying party can check that the input data is related to the
what-is-signed data by the specified (and signed) transforms.  But if the
transforms include some external data that isn't signed (for instance an
imported stylesheet referred to in an XSLT transform), then the relying
party can't be sure than both him and the signer are seeing the same
transforms - and if an attacker can control the transforms, he could
construct different transforms such that different input documents yield
the same result, i.e.

Input Document 1  +  Transform 1  ->  What-is-signed Document
Input Document 2  +  Transform 2  ->  What-is-signed Document (identical to
above)

Even though the signer intends to sign Document 1, the attacker can trick
the relying party into relying on Document 2.

So external transform data needs to be secured through some out-of-band
method, or needs to be covered by the XML-DSIG itself.  If the data is to
be covered by the XML-DSIG, should it be:
   a) referred to by a dsig:Reference in the dsig:Signature (and attached
as a signed attribute or something, if it's representable in XML)?
   b) referred to by a dsig:Reference in a dsig:Manifest to the
dsig:Signature?

Note that how this is done may affect Reference Validation, since the
original document's dsig:Reference should only be considered valid if the
external transform data's dsig:Reference is.  In other words, there's now a
dependence among the References.  So if it's done as (b), a dsig:Manifest,
the relying party isn't required to process the Manifest, which may have
security implications.



2. Signing Human-Readable data and XML -

The client may want to sign both an XML document and its human-readable
transformed version, for use in dispute resolution.  How should this be
done?

One approach is to include two dsig:Reference elements in the signature,
the first to the XML document, the second to the same document with
human-readable transforms applied.  Then a "policy identifier" of some sort
should be added as a signed attribute to indicate the relation of these
documents.

This approach will fail if the human-readable transforms behave
inconsistently when applied by the signing and relying parties (perhaps due
to implementation differences in the transform engines), and a
canonicalization transform for the transform output data is
unavailable.  This is (apparently) the case with XSLT transforms producing
HTML.

This could be solved by the signer storing the transform output data at a
URL, or sending it with the signature, and referring to it explicitly
instead of requiring the verifying party reproduce the transform
process.  But that may be inconvenient.

A different approach is to have the signer add a signed attribute
containing "transforms that reproduce what I was looking at when I chose to
sign".  Since processing these transforms isn't required to verify the
signature, it avoids the problem of having the signature fail if the signer
and verifier's transform engines produce slightly different
output.  However, if the engines *are* producing different output, there's
now wiggle-room for the signer to claim "oh, my transform engine produced
something different, that's not *really* what I was looking at when I chose
to sign".  So this may just shift the problem of "transform variability" to
a different place, not remove it.


-------------------->


The aforementioned TC  would like to know if the
XMLDSIG group has identified these issues during your work and in such case
if you have
came up to any conclusions about how they could be managed. If not, the TC
would
like to get your advice in order to address a suitable forum where to
address.

Best regards

Juan Carlos Cruellas.

Received on Friday, 11 April 2003 13:10:50 UTC