- From: Donald E. Eastlake 3rd <dee3@torque.pothole.com>
- Date: Sat, 06 Jan 2001 03:03:47 -0500
- To: Al Gilman <asgilman@iamdigex.net>
- cc: "Martin J. Duerst" <duerst@w3.org>, Rich Salz <rsalz@caveosystems.com>, Joseph Ashwood <jashwood@arcot.com>, w3c-ietf-xmldsig@w3.org, xml-uri@w3.org, dee3@torque.pothole.com
There are an infinite number of ways in which signed material can include external references, from URIs to arbitrary pieces of source or binary code to instructions to a human being to look something up to who knows what. And any standard for signatures never really has any idea how the stuff being signed is to be treated/interpreted/executed with the exception of some of the material in the signature construct itself. The semantics are all at the application level and the application must calll signature primatives to construct the signature in such a way that everything the particular application needs secured is secured. If some piece of XML is signed, how can the signature library know whether namespace URIs, or any other kind of extrnal reference in it, are to be used as is or perhaps only de-referenced after some some mapping or XSLT is done on it, assuming the signature library can even recognize the external references? And even if it could get past all those problems, how will it know whether the right thing is to secure the reference or the data referred to? If, say, the signed object is a recommendation of some service, then it is just the URI to the service, and maybe another key that that service uses to sign its results, that the recommender wants to sign, not some snap shot of some particular service results. Fortunately, I think the vast majority of XML signatures will be for protocol message use where most or all of these questions get decided as the protocol is designed. For the perhaps one in a thousand XML signatures that are on ad hoc generally interpreted documents, which seem to be all that you are considering, you really can't say much more than that you need to sign everything you want to secure. XMLDSIG has ample facilities for signing external DTDs, schemas, style sheets, etc., if appropriate. Donald From: Al Gilman <asgilman@iamdigex.net> Message-Id: <200101060400.XAA53464@smtp2.mail.iamworld.net> Date: Fri, 05 Jan 2001 23:05:53 -0500 In-Reply-To: <4.2.0.58.J.20010106120401.03a61a70@sh.w3.mag.keio.ac.jp> References: <3A5657E0.ED80542@caveosystems.com> <011c01c07768$c9b5e8a0$2a0210ac@livermore> >At 12:20 PM 2001-01-06 +0900, Martin J. Duerst wrote: >>[Cross-posting to xml-uri@w3.org. Sorry if this topic has >>already been hashed throgh there.] > >No, it hasn't been hashed to a conclusion. And I think it is separable. >_Grace a Dieu_. > >> >>I agree. Namespaces are also not intended to contain actual data >>such as payment information, and it's not ever agreed that the >>namespace URI should point to an actual document, nor how the >>document looks like, or that there would be only a single one. >> >>So proposing to always include a namespace document when signing >>is currently a non-starter. >> >>But there are cases where it's not too difficult to imagine >>that the namespace influences the meaning of the document. >>Imagine that a DTD contains the following: >> >><!ELEMENT payment-amount #PCDATA> -- amount in Italian Lire -- >> >>and is changed to >> >><!ELEMENT payment-amount #PCDATA> -- amount in British Pounds -- >> >>So the question is how to make sure that a namespace cannot >>easily be changed in such ways. This provides interesting >>challenges in lots of ways, and some input into the namespace >>and uri debate. It would definitely increase the stability >>of the transaction against attacks if the DTD that contained >>the above fragment could be singed. >> > >AG:: > >There is a generic problem of signing anything which has a dependency on an >include-by-reference other document. That is the case above. We need to >separate this from the disputes about namespaces. > >The trick is to use a trustworthy form of reference, for which a vanilla >URI-reference is in general not sufficient. [There may be URNs for which the >semantics of the scheme make the reference trustworthy.] However, a practice >involving chained signatures (the dependent document includes among its >[signed] data a counter-sign [checksum] for the depended-on document) is not >hard to construct. This belongs in the DSIG group, not XML-URI, I believe. >DSIG may wish to define a pattern of practice for such chained signatures that >will allow dependent documents to be signed without materially degrading their >trustworthiness as record instruments. > >There may well be names also drawn from the depended-on document, but >dependencies on anything in another document would constitute a semantic >extension of the base of existing consensus namespaces interpretation and is a >TBD hot spot as the archive of this list will show. The signature stuff >can be >healthy without getting tangled in this eelgrass. > >$.02 > >Al > >>Regards, Martin. >> >> >>At 01/01/05 18:25 -0500, Rich Salz wrote: >>>No, I think this is another example that points out that the signature often >>>must cover more than just the XML, but rather the stylesheets, etc., that >>>are related to it. I believe the XMLDSIG spec discusses this sufficiently. >>> /r$ >> >> >> >>The original posting, from Joseph Ashwood <jashwood@arcot.com>, >>for completeness: >> >> >>>> >>I've found a security risk in canonical XML that I believe needs to be >>covered. Simply stated through example (with probably large portions of xml >>left out): >> >>... >><... namespace declaration...> >><agreement>I agree to pay the amount(s) shown in the namespace</agreement> >>... >> >>once signed, can be later altered simply by changing the namespace >>declaration from reading "Purchase Barbie for 19.95" to "Purchase Ferrari >>for 150,000". The effect being that instead of getting a charge of 19.95 on >>the credit card, the charge becomes 150,000. We have seen these security >>risks become reality with servers being continually hacked all across the >>internet. I can think of no immediate solution outside of embedding the >>namespace file in the canonical XML. I don't think this problem will go >>away, it will just get worse. >> Joe >><<<< >> >
Received on Saturday, 6 January 2001 02:58:35 UTC