Re: ObjectReference shouldn't be signed, was RE: Location shouldn't be signed!

Hi,

From:  "John Boyer" <jboyer@uwi.com>
Resent-Date:  Thu, 28 Oct 1999 16:08:04 -0400 (EDT)
Resent-Message-Id:  <199910282008.QAA11039@www19.w3.org>
To:  "Donald E. Eastlake 3rd" <dee3@torque.pothole.com>,
            "Andreas Siglreithmayr" <andreas.siglreithmayr@ixos.de>
Cc:  "W3c-Ietf-Xmldsig (E-mail)" <w3c-ietf-xmldsig@w3.org>, <dee3@us.ibm.com>,
            =?iso-8859-1?Q?Reiner_H=FCttl?= <reiner.huettl@munich.ixos.de>,
            "Robert Frost" <robert.frost@munich.ixos.de>
Date:  Thu, 28 Oct 1999 13:07:46 -0700
Message-ID:  <NDBBLAOMJKOFPMBCHJOIIENOCBAA.jboyer@uwi.com>
In-reply-to:  <199910281308.JAA09629@torque.pothole.com>

>Hi all,
>
>I just wanted to briefly comment on this.  The problem addressed in Andreas'
>email is what happens when an externally validated resource moves from one
>location to another.  This is just a variation where one of the Location
>attributes is empty. Dave Solo and Richard Himes had an idea that we should
>be able to switch between signed data that is internally versus externally
>stored.

Regardless of how mobile the data is, the verifying application has to
be able to get its hands on it to verify its siganture.  If the
verifying application just magically knows, that's fine and you can
omit Location altogether.  But if the verifying application needs some
hint/name/whatever to find that data, you put that in Location.  There
are lots of ways you can encode this into a URI.  Of course,
signatures that use a URI for Location are not very interoperable, but
that's fine if that is what some application requires.  If someone is
writing an XML DSIG library, I don't think its reasonable to expect
them to include the ability to actually do gopher: or http: or any
other scheme (with the possible exception of the "data:" scheme) so
URIs will require a call out back to the application making the whole
thing application and possibly network connectivity dependent anyway.

>I like this, but I also like Don's solution to push that level of
>sophistication out to the Manifest and let the application add the
>processing rules to check the digest of the data.  So, your manifest would
>not contain an object reference but rather it would contain an element P
>that points to an object reference, which would in turn the data whose
>digest you put in the manifest with P.  Later, if you must change the object
>reference content or attributes, it will not break the signature and it will
>not break the digest of the data.

Indirecting the Location through a Manifest identified by an IDREF
means that the core signature doesn't encounter whatever sort of
Location you put in the Manifest but it's still the case that either
the application just knew where the data was, in which case you don't
need any Location at all, or it needs a hint, in which case the hint
can actually just about as well be in SignedInfo as in a Manifest.

>On the other hand, if we try to allow Location to be unsigned, we will also
>have to free up the transforms to solve problems like those posed by Solo
>and Himes.  The problem is that transforms like base64 were added so we
>could translate an internally stored resource to its native binary format
>before digesting it.  The idea is that one might like to store a word
>processing document in base 64 inside an XML document for delivery to a
>client desktop, but once there, the document could be separated from the
>enveloping signature XML and stored in native format on the desktop for
>viewing by application software.  This would require a change to the
>Location, but also a change to transforms to remove the base 64 decoder.

<Enter Humor Mode> I have any idea how to solve that.  Have type
dependent Transforms and allow run time type detection (a la fragment)
and pass the Content-Type along the Transforms pipeline... <Exit Humor
Mode>

>The same may be said of other types of transforms.  If you can conceive of
>changing the location of a web resource, then you may also want to change
>the location of the desired element(s) within the document.  This may imply
>a change to an XPath/XPointer/XSLT transform.

What we are headed for if you keep going this way is that basicly for
this type of signature, the core behaviour of verifying the digest(s)
in SignedInfo is wrong.  Of course, there are other XML digitial
signatures, particularly simple protocol messages, where verifying the
digest(s) is exactly the right thing.  If the digest isn't checked,
then it is real easy to point to a Manifest whose contents is totally
shufflable as to Location and Transforms.  As it is now, you can get
that effect by having SignedInfo point to a Manifest which points to a
Manifest.  The second level manifest will be totaly changeable with
any checking or enforcement completel application dependent.

>Since we would truly need to leave whole ObjectReference unsigned, not just
>Location, perhaps it is a good idea to wrap Don's pointer idea into the
>spec.  The main question is whether some of these things might be rare
>enough to push some of the processing on the application.

You want to sign DigestMethod and DigestValue.

>CONCLUSION
>==========
>Which shall it be?
>
>1) Use Don's proposal indirectly by pushing these problems off to
>application processing rules.

Seems easiest for right now and doesn't complicate things for the
simple protocol case.

>2) Add Don's idea of an object reference pointer to the dsig spec.
>
>John Boyer
>Software Development Manager
>UWI.Com -- The Internet Forms Company

Thanks,
Donald

>-----Original Message-----
>From: w3c-ietf-xmldsig-request@w3.org
>[mailto:w3c-ietf-xmldsig-request@w3.org]On Behalf Of Donald E. Eastlake
>3rd
>Sent: Thursday, October 28, 1999 6:09 AM
>To: Andreas Siglreithmayr
>Cc: W3c-Ietf-Xmldsig (E-mail); 'dee3@us.ibm.com'; Reiner Hüttl; Robert
>Frost
>Subject: Re: Location shouldn't be signed!
>
>
>Hi,
>
>From:  Andreas Siglreithmayr <andreas.siglreithmayr@ixos.de>
>Resent-Date:  Thu, 28 Oct 1999 04:27:09 -0400 (EDT)
>Resent-Message-Id:  <199910280827.EAA17052@www19.w3.org>
>Message-ID:  <9F077EBC72BFD211AEF90060080F37366C79FB@muc-mail4.ixos.de>
>To:  "W3c-Ietf-Xmldsig (E-mail)" <w3c-ietf-xmldsig@w3.org>
>Cc:  "'Joseph M. Reagle Jr.'" <reagle@w3.org>,
>            "'Donald E. Eastlake 3rd'"
>    	 <dee3@torque.pothole.com>,
>            "'dee3@us.ibm.com'" <dee3@us.ibm.com>,
>            =?iso-8859-1?Q?Reiner_H=FCttl?= <reiner.huettl@munich.ixos.de>,
>            Robert Frost <robert.frost@munich.ixos.de>
>Date:  Thu, 28 Oct 1999 10:27:37 +0200
>
>>I wrote several weeks ago (  How to sign several resources (XML and
>XSL)? ).
>>
>>	First a question to Donald Eastlake and Joseph Reagle:
>>
>>	IXOS wants to participate actively in the XMLDsig Working Group.
>>
>>	How can someone of IXOS become a member of the working group?
>>
>>	Please reply to reiner.huettl@ixos.de and robert.frost@ixos.de.
>
>As a joint IETF/W3C working group, you can do so by just subscribing
>to the mailing list.  Send mail to w3c-ietf-xmldsig-request@w3.org
>with "subscribe" in the subject line.  The working group decision
>process is the IETF mailing list consensus process.  You can also
>ask Joseph Reagle to list you on the participants web page.
>
>>Now my suggestion:
>>
>>In the draft Section 6.0 is described, how to generate a signature.
>>
>>It says, that the signature is calculated over SignedInfo.
>>
>>Signed Info includes the information about the locations of the  data to be
>>signed.
>>
>>I think this isn't practically usefull, because the location in the web or
>>on a server of a  DTD or a stylesheet, which are signed could change.
>>
>>If someone wants to change the position of signed data, all XML signatures,
>>which references to this position have to be recalculated otherwise it
>>couldn't be  verified.
>>
>>One solution would be a package, of course. But think about someone who
>>signs several pictures.
>>The person have to embed the data of the pics in the xml document.
>>That would make the xml huge.
>
>In our current vocabulary, I think you mean an Object the includes the
>actual data being signed.
>
>>The easiest solution would be not to sign the location.
>>
>>Another solution made by a colleague of me would be to allow a reference to
>>point to a reference, that points to the position of the proper data.
>>I think about something like the following:
>>
>><Signature>
>>	<SignedInfo>
>>		(CanonicaliziationMethod)
>>		(SignatureMethod)
>>		<ObjectReference Id=? Location="#reference1" Type=reference
>>>
>>			(Transforms)
>>			(DigestMethod)
>>			(DigestValue)
>>		</ObjectReference>
>>		....
>>	<SignedInfo>
>>	(SignatureValue)
>>	(KeyInfo)
>>	(Object)
>>	...
>>	<Reference Id = "reference1" Location=? Type=? />
>>	...
>></Signature>
>
>The way to get the effect of what you have above under the current
>draft is to have the SignedInfo ObjectReference point to an Object
>containing a Manifest and put this second level pointer inside the
>Manifest.  In either case, the core behaviour will check the signature
>on the "Reference" or Manifest but it would be up to the application
>whether it checks the digest in the Manifest or uses any Location
>provided in the "Reference".
>
>Alternatively, you really can't check the signature without getting
>your hands on the data somehow.  If you put some sort of URL in the
>SignedInfo ObjectReference Location, like
>http://example.ixos.de/cgi/document-finder?special-document-serial-number
>then presumably the core signature verfier would do a call-out to
>fetch the data from this URL and your cgi could get the data from
>where ever it is.  If there is no way to reliably get the real data
>you are trying to secure, there is not way to secure it.
>
>>> -----------------------------------------------------------
>>> Andreas Siglreithmayr
>>> Intern
>>> Innovation
>>>
>>> iXOS Software AG
>>> Technopark Neukeferloh
>>> Bretonischer Ring 12
>>> D-85630 Grasbrunn/München
>>> NEW TELEPHONE NUMBERS!!
>>> Phone: (+49)-(89)-4629-1136
>>> Fax: (+49)-(89)-4629-331136
>>> World Wide Web: http://www.ixos.com/deutschland
>>> E-Mail: andreas.siglreithmayr@ixos.de
>
>Thanks,
>Donald
>

Received on Friday, 29 October 1999 10:47:06 UTC