W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > October to December 1999

ObjectReference shouldn't be signed, was RE: Location

From: <rhimes@nmcourt.fed.us>
Date: Mon, 08 Nov 1999 12:25:22 -0700
Message-Id: <9911089420.AA942089206@nmcourt.fed.us>
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] --> 


<!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.

Received on Monday, 8 November 1999 14:27:01 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:21:32 UTC