- From: <rhimes@nmcourt.fed.us>
- Date: Mon, 08 Nov 1999 12:25:22 -0700
- To: <w3c-ietf-xmldsig@w3.org>, <reagle@w3.org>, <aschmidt@darmstadt.gmd.de>
- Cc: <w3c-ietf-xmldsig@w3.org>, <reiner.huettl@munich.ixos.de>, <robert.frost@munich.ixos.de>
John Boyer wrote: >This is contrary to one of Dave Solo's earlier design principles. The >main thing I'm pointing out is that if we remove this invariance, then we >must also allow Transforms to vary. A scenario communicated to us by Rich >Himes is as follows: >Use XML file with data enveloped to deliver signed data to desktop. Once >on desktop, switch data to residing on desktop, and change URI to point to >that data, then remove the copy of the data from the XML file (making it >much smaller), and store the detached signature for possible later use. And, to underline what John is implying, the data transform is no longer base64, but native, so the transform and the location both change. >Unfortunately, the digest value needs to be signed or there is no >security, so we must sign ObjectReference. So we either sign the whole >thing and live with invariance (using Don's manifest ideas and application >processing rules to accomplish the desired effect), or we do something >like add Transforms to omit the things that the primary signature >shouldn't sign (like Location and/or Transforms in the ObjectReference). For reference (19991022): <!ELEMENT ObjectReference ( Transforms?, DigestMethod, DigestValue ) > <!ATTLIST ObjectReference Id ID #IMPLIED Location CDATA #IMPLIED> Type CDATA #IMPLIED> <!-- The values of Location and Type conform to the productions specified by [URI] --> and <!ELEMENT Object ANY> <!ATTLIST Object Id ID #IMPLIED Type CDATA #IMPLIED Encoding CDATA #IMPLIED > <!-- Where type and encoding CDATA conforms to the productions specified by [URI] --> We "must" sign the digest method and digest value (and type?) but I believe it should not be a requirement for location or transforms to be signed. Some applications may require these to be signed, so it should be an option. Seems to me that logically, ObjectReference refers to Object which in turn should allow the data format and location to vary without breaking the signature. It is precisely the same data semantically, and that is what we should be signing (a type of canonicalization). Forcing applications to freeze the location will be a huge problem in the long run, IMO, even if it isn't a URL. Likewise, freezing the transform will be a problem for the longevity of the signature in some cases. (I just realized that allowing location to change helps resolve the ID conflict when documents are merged.) One way to do this is for the Transforms element of ObjectReference to specify a transform on Object (rather than it's content), to allow exclusion of a location/transform within Object (transform is not currently specified in object). I'd like this to be more natural though, by adding an attribute to ObjectReference, for example. Thanks, Rich
Received on Monday, 8 November 1999 14:27:01 UTC