RE: Locations but not Transforms as hints (was RE: The XML-DSig N on-standard, or Location/Transforms as 'hints')

Hi Mark,

Comments below...

-----Original Message-----
From: w3c-ietf-xmldsig-request@w3.org
[mailto:w3c-ietf-xmldsig-request@w3.org]On Behalf Of Mark Bartel
Sent: Wednesday, November 24, 1999 11:32 AM
To: 'John Boyer '; 'w3c-ietf-xmldsig@w3.org '
Subject: RE: Locations but not Transforms as hints (was RE: The XML-DSig
N on-standard, or Location/Transforms as 'hints')

My thoughts on each:

1. Core behaviour should be free of application-specific behaviour.

I agree with this in theory. My point was that there are other issues in the
core that are also application specific, such as how the application gets
the appropriate key material.

<John>
Appropriate key material is obtained from KeyInfo. I realize that more
non-core work must be done to associate the key with the signer (e.g. by
doing a certificate chain dance), but that is done in accordance with a PKI
policy, not a specific application.  Furthermore, it can be done either
before or after-- not during-- the operation of core behavior.
</John>

I don't see location-as-hint as posing a noticeable interoperability problem
or implementation burden.  Applications that do funky things will of course
not interoperate, but that is a given.
Location-as-hint significantly simplifies some particular scenarios, and I
think that in this case it is worth the slight amount of effort required to
do it.  However, assertions-about-assertions could be used to the same
effect; they are merely more complicated.

<John>
As I've explained often in the past, creating some fix for Location does not
solve the whole problem.  You still have to optionally omit a base 64 decode
AND an Xpath transform with the value child::text() in order to be able to
move a signed resource from within a document to without.
Location as hint makes Location an application-specific behavior as a way of
hacking around the problem of wanting to omit the location from SignedInfo.
The real problem is much bigger, so until your proposal talks about solving
the whole problem, why are we debating over its merits?  But since I'm in a
debating mood, let's consider a location such as
URI="http://www.somecompany.com//somedocument.txt".  Isn't it at least
slightly bothersome that core behavior can't go and dig up this resource?
Isn't it at least slightly bothersome that core behavior has to have an
application callback setup to resolve this?  Isn't it at least slightly
bothersome that we have no idea what additional information that callback
will need (dates, people, originating organizations, etc.)?
Wouldn't it be a lot simpler if we either
A) gave the ability to precisely define what should be omitted from
SignedInfo using an Xpath transform
or
B) recognize that we view Location resolution (and any incumbent change of
transforms) as application-specific and move the whole problem out to the
Manifest.

In fact, it is already possible to solve this problem using a manifest, as
will be explained in another email.
</John>

2. The signer of the document, not the verifier, determines what is
important to be signed.

I disagree with this.  I think both the signer and the verifier do this
determination.  It depends on the nature of the interaction.  I submit the
following points:

a) The signer cares that *sufficient* information is signed.
b) The verifier only cares that the information relevant to it is signed.
c) If the verifier chooses to ignore signed information, that doesn't change
the assertion that the signer made.
d) If the signer is making an assertion intended to have legal force (which
will frequently not be the case), they will be concerned that information
that they are *not* asserting is *not* signed.

If location is signed, the document is moved, and the verifier doesn't care,
that doesn't change the assertion that the signer made.  This is points a),
b), and c).

And since it doesn't particularly matter where the bits come from, I would
say that we should specify the signed location to mean that "this is where
the resource was when I signed it" and nothing more.  Therefore d) would not
be an issue.  I don't think it is reasonable for the assertion to be "this
is where the resource will be for all time".  If the verifying application
requires that the resource be at the original location, it can do that check
itself.  It seems to me that this is a lot like requiring an original of a
contract rather than a photocopy; it is the recipient for which this
matters.  Sometime an organization will accept a copy, sometimes it won't.

<John>My differing position on this should be evident from the comments
below.</John>

3. Location-as-hint is a "brutal hack" that changes the meaning of what got
signed.

I disagree, but I realize that I am thinking of the signed location in the
sense of the above paragraph.  The signed location is the "original" which
may or may not still exist.

<John>
Although this was not a 'big' point as I am more concerned about allowing
core behavior to dig up the bits, this is obviously a point on which we must
agree to disagree.  To me, a signature should sign what the signer intends
it to sign.  The URI is signed because of a design limitation in our core,
not because the user intended to sign it.  The solution is a brutal hack
because it tries to fix the problem by saying that
URI="http://www.somespecificcompany.com/somespecificdocument.txt" does not
have a set meaning. To me this is like curing the disease by amputation.  In
the world of medicine, it works and is sometimes necessary, but it is brutal
and only used as a last resort.  We should not consider this option when
there are at least two better options on the table.

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

</John>

Received on Wednesday, 24 November 1999 16:07:35 UTC