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

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.

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.

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.

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.

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.

CONCLUSION
==========
Which shall it be?

1) Use Don's proposal indirectly by pushing these problems off to
application processing rules.
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


-----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 Thursday, 28 October 1999 16:07:57 UTC