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

[Robert Zuccherato <robert.zuccherato@entrust.com>]

Title: Fw: From OASIS digital signatures services TC: request of comments

Ed Simon, on the XMLDSIG list, could not post this message to the DSS list as he is not a member.  He asked me to forward this on.

----- Original Message -----
From: "Ed Simon" <edsimon@xmlsec.com>
To: <w3c-ietf-xmldsig@w3.org>
Cc: <dss@lists.oasis-open.org>
Sent: Friday, April 11, 2003 1:10 PM
Subject: 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.
>