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

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

From: John Boyer <jboyer@uwi.com>
Date: Wed, 24 Nov 1999 15:38:04 -0800
To: <tgindin@us.ibm.com>
Cc: "DSig Group" <w3c-ietf-xmldsig@w3.org>, "Mark Bartel" <mbartel@thistle.ca>
Message-ID: <NDBBLAOMJKOFPMBCHJOIMEHACCAA.jboyer@uwi.com>
Actually, they were clear.
The bottom line is that the URI that indicates the current location *is not
being signed*.  This is just another processing rule that says, in essence,
omit the location from the SignedInfo.
The only difference is that, unlike a signed XPath transform on SignedInfo,
the solution is incomplete as it does not solve two out of the three
scenarios put forth at FTF#3.
Why not?
Consider the scenario where you want to move a signed resource from within
an element in base64 to an external location in raw format.
Not only must you change the location URI from "" to "something", but you
must also consider the transforms that were necessary to obtain the resource
when it was in the document.  The data would've been identified as being
within some element X either by an IDREF or as part of an XPath.  When the
document is external, the IDREF must go (or the portion of the XPath that
identified X must go).  For simplicity, I will use XPath since the XPath is
necessary anyway.  Once you have X, you still need an XPath transform to get
the child text node because the base-64 decoder will blow chunks on X's
start tag.  Thus, an XPath like "//[@id="X"]/child::text()" must be in the
transforms *before* the base64 decoder when the signed resource is within
the document.  When the signed resource is moved outside of the document,
both the XPath and the base64 decoder must be removed.

Thus, it is also necessary to omit things besides just the location.
Furthermore, the solution is not just as simple as moving location, idref
and transforms outside of SignedInfo, as I have stated in numerous prior
emails to the archive.  If one is going to omit certain transforms, security
breaks unless one can state precisely which transforms can be omitted from
SignedInfo.  We have a precision language called XPath that solves this
problem as long as we make the constraint that the SignedInfo transform
cannot omit itself from SignedInfo, it is possible for a human to judge
whether the signature created with our specifications are secure (e.g. even
if someone omits DigestValue or DigestMethod, it will be evident in the
SignedInfo transform).

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 tgindin@us.ibm.com
Sent: Wednesday, November 24, 1999 3:05 PM
To: John Boyer
Cc: DSig Group; Mark Bartel
Subject: RE: Locations but not Transforms as hints (was RE: The XML-DSig
Non-standard, or Location/Transforms as 'hints')


     John, I guess the field names weren't clear enough.  Location would be
assumed to be fixed in all cases, while currentLocation would be treated in
the same way as "location-as-hint" by a verifier (current refers to the
time of signature).  I was just providing separate names for the separate
uses, and trying to make the names illuminate the difference.  It would
make little difference whether currentLocation were signed or not, since
the assertion embodied by the field value is not falsifiable by a later
verifier, and breaking it by moving the reference doesn't imply anything
about breaking the signature.

          Tom Gindin

"John Boyer" <jboyer@uwi.com> on 11/24/99 04:49:07 PM

To:   Tom Gindin/Watson/IBM@IBMUS, "DSig Group" <w3c-ietf-xmldsig@w3.org>
cc:   "Mark Bartel" <mbartel@thistle.ca>
Subject:  RE: Locations but not Transforms as hints (was RE: The XML-DSig
      Non-standard, or Location/Transforms as 'hints')




This is precisely my point. It's a problem because our design forces the
signing of something that either prevents core from solving a class of
problems or requires core to depend on application specific location
resolution using the URI as a hint.

The currentLocation field does not contribute anything, it just moves the
same omission argument to a different attribute.

Regardless, the point is that if we could omit location from the
SignedInfo,
then the Location is free to be changed to the value desired.  It should be
noted, though, that there is a second (I would argue more important) class
of problems that MUST have the location signed, so the trick is whether we
can get core behavior to be configurable (omit  if told to omit, or don't
omit by default).
(snip)

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


-----Original Message-----
From: tgindin@us.ibm.com [mailto:tgindin@us.ibm.com]
Sent: Wednesday, November 24, 1999 1:32 PM
To: John Boyer
Cc: Mark Bartel
Subject: RE: Locations but not Transforms as hints (was RE: The XML-DSig
Non-standard, or Location/Transforms as 'hints')


     If location were unsigned, location-as-hint would not be a "brutal
hack" - it could be redefined as follows: "Location: the value of this
field is the URI at which the resource was located when the signature was
created".  It is only a hack because we are making the signer sign it, and
then saying "don't take this too seriously".
     For that matter, if we had two different names whose use was mutually
exclusive, "Location" and "currentLocation", and "currentLocation" was
omitted from the signature base when present, there wouldn't be much of a
hack either.

          Tom Gindin
Received on Wednesday, 24 November 1999 18:39:25 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.29 : Thursday, 13 January 2005 12:10:08 GMT