RE: Omitting Location and Transforms from SignedInfo

Hi Jim,

I agree to your desire to push this off to a Manifest, but only if we change
the core syntax so that external references are just plain not supported.
See below.

-----Original Message-----
From: w3c-ietf-xmldsig-request@w3.org
[mailto:w3c-ietf-xmldsig-request@w3.org]On Behalf Of Jim Schaad
(Exchange)
Sent: Wednesday, November 17, 1999 1:12 PM
To: 'Joseph M. Reagle Jr.'
Cc: DSig Group
Subject: RE: Omitting Location and Transforms from SignedInfo


Some responses to this message:

1.  The behavior you described is easily obtainable in the current syntax by
putting all of the object references in a manifest and then putting the
object reference to the manifest in the document.  We check the signature,
check the digest on the manifest and stop processing.  The application can
then do whatever verification it things are necessary on the object
references in the manifest. (I actually was originally an opponent of having
more that the reference to the manifest in the signed info, but there were a
large number of people who wanted the current behavior.)

<John>
Yes, I think I'd be one of them.  Shouldn't it be the case that core
behavior creates a digital signature covers the data that the user actually
wanted to sign?
If we use the current syntax, then that means that every place the signature
travels, it must be possible for core behavior to dig up the bytes being
reference by URL (since they may not be in a local cache).

We could change the syntax to that recently proposed in one of my emails.
This would mean that someone would need to put the data in the current
document if they want to sign it.  To me this is an acceptable limitation.
If you want to sign something outside of the document, then use a Manifest.
This sounds exactly like what you're proposing, except we don't have a
Location in the core syntax because we don't support external references in
the core syntax.

John Boyer
Software Development Manager
UWI.Com -- The Internet Forms Company

</John>

2.  Location is, always has been and always will be in the end a hint.  If
an application wants to add the semantics that the location must be correct
it can, however the fact that the document is not retrieved from the
location specified does not change the validity of the signature.  Trying to
add this will get lots of people, especially lawyers, a lot of work and
nothing else.  If I sign a document and refer to a set of conditions and
terms on a web sight, the fact that the list of conditions gets updated does
not invalidate my signature.  In the event that you want to prove something
for the purpose of enforcing a signature, one would grab and save the
documents referred to and save them with the signature.  The fact that the
documents are not at the same location DOES NOT change the validity of the
signature, nor does the fact that you cannot prove that the document came
from that location.  The important thing is that the digest of the document
you are presenting as coming from that location matches the digest of the
document being signed.

3.  The current wording of the document says:

    1. locate object and apply Transforms  to the specified resource
       based on each ObjectReference(s) in the SignedInfo element.  Each
       transform is applied in order from left to right to the object
       with the output of each transform being the input to the next.

This does not imply in my mind that the location is the only place that the
object can come from.  It merely says find the bytes for the object.


jim

Received on Wednesday, 17 November 1999 18:12:54 UTC