[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: From OASIS digital signatures services TC: request of comments
There it comes the first answer to our request. BTW, I will be out of the office (half holidays and half work) during the next week so I guess that if our list is closed, answers will directly come to my email address we will not be able to access them until then... unless there are not other means (I know that we have our open list but I was not sure whether the TC wanted the reaction from W3C be seen by all the people accessing to that open list..) Regards Juan Carlos. >Return-Path: <david.wall@yozons.com> >From: "David Wall" <david.wall@yozons.com> >To: "Juan Carlos Cruellas" <cruellas@ac.upc.es> >Subject: Re: From OASIS digital signatures services TC: request of comments >Date: Fri, 11 Apr 2003 09:14:42 -0700 >Organization: Yozons, Inc. >X-MSMail-Priority: Normal >X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 >X-Spam-Status: No, hits=-0.5 required=6.0 > tests=MAY_BE_FORGED,NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES, > SPAM_PHRASE_00_01,USER_AGENT_OE > version=2.43 >X-Spam-Level: > >>From a contracts perspective, you need to sign what the user saw. This is >pretty clearly stated in the E-Sign Act in the U.S. Signing underlying >data, while fine for also having the data input into a form, for example, is >not the legal instrument that the user signs as the user will not be able to >make a good judgement that the XML data itself if what he intends to sign. >Data is data, and the intent will be much harder to ascertain by just >looking at the data without seeing it in-line in the viewable format. > >This is also true for signing Word or HTML. It's possible with those >formats to include invisible elements, such as using a white font on a white >background. However, it is clear that the courts will uphold what is >viewable from what the actual data says since it is unreasonable to expect >that people can understand the raw data over what was presented to them for >signatures. > >David > > >----- Original Message ----- >From: "Juan Carlos Cruellas" <cruellas@ac.upc.es> >To: <w3c-ietf-xmldsig@w3.org> >Cc: <dss@lists.oasis-open.org> >Sent: Friday, April 11, 2003 8:42 AM >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. >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]