From OASIS digital signatures services TC: request of comments

[Juan Carlos Cruellas <cruellas@ac.upc.es>]

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.