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

Hi John,

I think perhaps that I have misunderstood what people have been meaning by
"location as hint".  To me it means that the application can choose to
ignore the signed location and locate the object by other means.  Other
means may be an unsigned location elsewhere in the signature that we specify
in the standard.  Or, the application can ignore both the signed location
and the standard unsigned location and do something else.  Or, the
application can decide that since it can't verify the signed location and is
not willing to trust the unsigned location, it will not verify the
signature.  I don't see any inconsistencies here.

Transforms within SignedInfo being viewed as hints:  I never meant to imply
that you had supported this.  I was merely trying to clarify what my own
position was.

Transforms outside of SignedInfo:  we both object to them, just to differing
degrees.  The reason I don't object as strongly as you do is that the
application can decide which transformations to trust.  Note that the
Transforms outside of the SignedInfo can be signed by another signature, and
applications can use *that* as a criteria for trust.  However, I would
prefer that we let applications deal with that issue and not have Transforms
outside of SignedInfo.

Your example:  this is not a problem I was trying to solve.  My main concern
was for the x.com to y.com or base64 on web to unencoded on disk type of
changes, which my concept of "location as hint" addresses.  I was not trying
to deal with the general document transmogrification case; do we feel this
is a problem we need to solve?

Removing location from the core syntax:  I see this rather as "removing the
contentious elements" rather than throwing "out all of the stuff that most
people really dislike".  Although perhaps that is just as good.  However, I
get the impression that we are making progress with the current spec and
personally don't feel that we need to do something that drastic to resolve
the issues.

-Mark Bartel
JetForm Corporation


-----Original Message-----
From: John Boyer
To: Mark Bartel; w3c-ietf-xmldsig@w3.org
Sent: 11/22/99 4:16 PM
Subject: RE: Locations but not Transforms as hints (was RE: The XML-DSig
Non-standard, or Location/Transforms as 'hints')

Hi Mark,

-----Original Message-----
From: Mark Bartel [mailto:mbartel@thistle.ca]
Sent: Monday, November 22, 1999 12:08 PM
To: 'John Boyer '; 'w3c-ietf-xmldsig@w3.org '
Subject: RE: Locations but not Transforms as hints (was RE: The XML-DSig
Non-standard, or Location/Transforms as 'hints')


Hi John,

I must admit, I don't understand why viewing location as a hint is so
problematical.  If we allow (and specify) a location to appear outside
of
SignedInfo, the application can use the signed location, unsigned
location,
or something else if it wants.  For the common resource-has-moved from
a.com
to b.com case, this makes everything very simple.  If the verifier is
willing to use the unsigned location, it will just do the same
processing as
it would for the signed location.  I imagine that the unsigned location
would be put in SignatureProperties.  I just don't see how this would
require "a small army" to implement or maintain or how this is choosing
"to
not address these people's problems with core behavior".

<John>
In this paragraph, you are arguing my principal point for me, then
representing it as contradictory to my viewpoint.  I don't understand
how
that happened, but if one uses the point one is arguing against to argue
against itself, then it doesn't have a good effect on one's conclusion.
Specifically, the contentious issue is whether Location is to be used by
core behavior or whether Location is a hint to be resolved by
application
behavior.  You are telling me that one solution would be to have both a
signed and unsigned Location.  This implies a model where you want core
behavior to dereference the Location, either signed or unsigned.  If
Location were used only as a hint, there would be no need to have both a
signed and unsigned one.  The model I've been pushing for all along is
one
in which, if external document references are included in core behavior,
then they must be resolvable by core behavior.  (So, we either define
how
core resolves external locations or we punt all external references to
the
manifest with all of the rest of the app-specific behaviors).
</John>

I acknowledge that it is not as "clean" a design since location is in
two
places when a resource has moved, but it is certainly simpler
conceptually.
Another advantage to the location-as-hint is that is allows the verifier
to
decide trust, rather than the signer.

<John>
OK, now we have an interesting segue.  You're moving from having two
locations for core behavior to using location as a hint, which implies
not
core behavior but rather application behavior in the form of a callback
function to resolve the location into a bag of bits.
</John>

The Transforms-over-SignedInfo solution requires that applications to
implement XPath or XSLT transforms simply to be able to move a resource
that
doesn't require any Transforms at all.  I don't like this.

<John>
1) The transforms over signed info is only one way to solve the
scenarios in
hand; it just happens to be a good one.

2) We are talking about core behavior, not applications.  If transforms
over
signedinfo happens, then anyone who gets a copy of reference code from
alphaworks or W3C will already have this implemented in their
application.
It's a do-nothing for the application developer.  Further, it should not
be
a problem for at least the W3C to provide XPath as part of this; after
all,
if the W3C won't even implement its own recommendations, then should we
bother with the W3C?  No.  Hence, they can and will build it if it is
required by our work.

3) Even if an application were doing this, they would only need to
support
enough XPath to get their own application to work.  The idea is not
necessarily that everyone can validate everyone else's signatures but
rather
that we have a consistent notation that uses standards to express
everyone's
signatures such that it is *possible* for *someone* (not everyone) to
create
a master validation program that could validate any core XML signature.

4) I've never been in favor of the XSLT transform.  I only wanted XPath
as a
precision language for filtering documents and achieving document
closure.

4) Perhaps we are going overboard in requiring core behavior to do any
digging up of bits outside of the current document, whether by its own
devices or whether by application callback.  Why don't you have a look
at
the simplified syntax I proposed recently and see if it makes sense.  It
has
several advantages, including

a) dumping XSLT (but not XPath),
b) separating core behavior from external resource location
c) cleaner separation between core and those things which MUST be
application-specific
d) applying encrypted hash directly to data in document.
e) others listed in that "Simplified Syntax" email.

</John>

I admit that viewing location as a hint does not address the problem in
some
scenarios where the document is transformed by other processes (such as
embedding the document in another document).  I'm happy to leave that to
the
application.  If I recall correctly, the origin of this debate was "What
if
the location changes?" in the changing-URL sense and not "What if we
transmogrify the original document?"

But I have only minor misgivings about having additional Transforms
appear
outside of SignedInfo.

<John>
I have strong misgivings about allowing arbitrary transforms outside of
SignedInfo.  It is possible to hijack signatures in precisely the
'favorite
color' way you described in a previous email if we allow arbitrary
transforms outside of SignedInfo.
This is why I wanted to XPath transform SignedInfo itself.  Provided
that we
have the simple 'bottom turtle' processing rule that the XPath cannot
omit
itself, the XPath can very precisely identify the base 64 transform to
omit
from an object reference.  Thus, one could only have or not have a
base64
transform, and ObjectReference transforms could therefore NOT be
arbitrarily
modified.
</John>

My strong objection is to the Transforms within SignedInfo being viewed
as
hints.

<John>
I have never, never, never, never, never supported this option.
Hopefully
from that which is above and below, you will see how my position differs
from this.
</John>

In other words, I feel that we could allow Transforms outside of
SignedInfo
as
long as the unsigned transforms were applied, and then ALL of the signed
transforms were applied.  Applications can decide what unsigned
transforms
they wish to trust.

<John>
It is easy to see how the security of this suggested rule breaks.
Simply
consider the actual problem we are trying to solve. When a document is
internally stored in element E, we must do the following:

IDREF (or barename XPointer transform) to indicate E
XPath child::text()
Base64 decode.

Since the base 64 decode happens last, all of the transforms are
unsigned
and there are no signed transforms.  Thus, the object can be arbitrarily
modified in the unsigned transforms with no possibility of reality
checks by
the signed transforms.  In general, the signed transforms won't be able
to
run reality checks that secure this method even if they did exist.

In conclusion, then, arbitrary unsigned transforms are a very, very bad
idea, leading to precisely the problems *you* identified in prior emails
to
this group.  If we are going to omit a transform from an
ObjectReference, we
need some digitally signed description of *precisely* what that is so
that
the description can pass a security audit as a non-threat.  This is the
essence of document closure as applied to SignedInfo itself.

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

Received on Monday, 22 November 1999 17:58:59 UTC