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

Locations but not Transforms as hints (was RE: The XML-DSig Non-s tandard, or Location/Transforms as 'hints')

From: Mark Bartel <mbartel@thistle.ca>
Date: Fri, 19 Nov 1999 11:49:44 -0500
Message-ID: <91F20911A6C0D2118DF80040056D77A2032B85@arren.roke.thistle.ca>
To: "'John Boyer '" <jboyer@uwi.com>, "'DSig Group '" <w3c-ietf-xmldsig@w3.org>
Hi John,

First, preliminary comment:  you say that there are two positions.  You
characterize one of them being that Location and Transforms are only a hint.
Well, I don't think I'm the only one who is perfectly happy with Location as
a hint (with an Encoding attribute which is also a hint) but strongly
opposed to Transforms being a hint.

So, I agree with you that Transforms should always be done but disagree
about Location.

I believe the only problem you have with Location as hint is that a callback
is "required" that otherwise wouldn't be.  All of your other issues seem, to
me, to be only relevant to Transforms as hints.

With respect to the callback issue, I don't see it as a problem.  I expect
that most libraries will provide a hook, but "do the normal thing" (grab
whatever is at Location) if you don't provide a callback.  Providing a
callback would only be necessary when you expect documents to move.  Said
callback may be as simple as "here's the URI and Encoding in Location, give
me back the real URI and Encoding".  On the other hand, it may be "here's
the URI and Encoding in Location, give me a byte stream".  Either way, it
doesn't seem an heavy burden to lay on applications.

Of course, the only time that an application needs to not "do the normal
thing" is when the document may move.  If the document stays put, there is
no issue and no interoperability question.  I believe that the necessity of
being able to move the documents has been quite well expressed.  I also
believe that finding the document once it has moved is very
application-specific.  Viewing the Location as a hint (with an Encoding
attribute that is also a hint) seems to me a wonderfully simple way of
dealing with the travelling document problem.

-Mark Bartel
JetForm Corporation

-----Original Message-----
From: John Boyer
To: DSig Group
Sent: 11/18/99 6:26 PM
Subject: The XML-DSig Non-standard, or Location/Transforms as 'hints'

One of the main points that has caused much of the recent debate over
signing location and transforms is that some of us believe that

1) the ObjectReference's Location and Transforms will tell core code how
obtain the bucket of bits digested in DigestValue.

while others of us believe that

2) the ObjectReference's Location and Transforms are a hint that 'may'
the application find the bits that the core code will need to do the

I'm having difficulty buying into this latter point of view because I
that far too much work is being pushed off to the application, which to
means that most signatures will not validate outside of their
domains.  I don't see the point in having a 'standard' if the result is
applications don't interoperate.

From an API point of view, proponents of the first idea seem to want to
CreateSignature() or VerifySignature() and give a pointer to a Signature
element.  Proponents of the second idea seem to want the same thing,
that they must first set up an application-specific callback function
CreateSignature() and VerifySignature() can use to help dig up the
bits.  Therein lies the rub.  Callbacks are a wonderful way to solve
problems if you don't care about globally secure resources, application
interoperability, and so forth.  The first idea is in many of our minds
because we associate 'standard' with interoperability.

When the signer creates a signature, we are saying that Location and
Transforms provide 'hints' that indicate how the signer created the
of bits.  Presumably, when the signer signed, the Location and
describe precisely what happened.  So, we are basically saying that the
verifier can treat these as hints rather than precise steps.  So, the
meaning of these *signed* bits has changed without breaking the
I agree that it will work in any single application context, but it has
unappealing engineering aesthetic.

Finally, when proponents of the second idea say that Transforms are
does this mean that we will be making each application responsible for
resolving the Transforms too?  In other words, going back to the idea of
callback function, must the callback function resolve the Location or
it resolve the Location and Transforms, giving to core code the exact
set of
bits that should match the DigestValue once the DigestMethod is applied?

John Boyer
Software Development Manager
UWI.Com -- The Internet Forms Company
Received on Friday, 19 November 1999 11:49:53 UTC

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