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>

-Mark Bartel
JetForm Corporation


-----Original Message-----
From: John Boyer
To: Mark Bartel; 'DSig Group '
Sent: 11/19/99 4:40 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: Friday, November 19, 1999 8:50 AM
To: 'John Boyer '; 'DSig Group '
Subject: Locations but not Transforms as hints (was RE: The XML-DSig
Non-standard, or Location/Transforms as 'hints')

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.

<John>
Aside from our agreement over Transforms not being a hint, my comments
were
actually mostly about my expectation that Location should indicate where
the
object is rather than be a hint about where the object is.  As you can
tell
from the bottom of my letter, I cannot tell at this point whether
Transforms
will be handled by core code or also serve as hints.  Naturally, I'd
prefer
that they were not hints.

The issues I raised were
1) the Location as hint implies need for application-specific callback
2) meaning of Location can change from signer to verifier without
breaking
signature.  To me, this means that the Location shouldn't be signed.
</John>

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.

<John>
To me it's not the end of the world if we lay this on applications.
It's
not like security is broken or anything.  It's just that we are in fact
saying that there are classes of applications (given by those scenarios
I
presented) for which core validation logic will not work.  These
applications will not be able to have their signatures validated by
other
applications.

Basically, we sign the Location so that it cannot be changed. Our
solution
is that Location can be completely wrong but serves only as a hint that
applications are free to interpret in some completely different way.
This is
a very clever way of saying that we don't see how to make core behavior
do
what these people want to do.  We broke their apps by signing Location
such
that the 'do the normal thing/grab the bytes' behavior doesn't work, and
we
are deciding not to fix this break when their clearly is a solution.

People who have these problems I've described would like their
signatures to
validate by core behavior just like those of us who don't have the
problems
they face.  I would think that anyone involved with a company that has
to do
workflow on other companies' documents would be concerned about the
long-term maintenance fiasco that results from having to write a special
module for each document type to deal with the special Location
resolution
methods of that application.  Over time, as each company tweaks and
changes
its application logic, one might need a small army to keep up with the
potential changes.
</John>

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.

<John>
Nice play on words!  I agree that we have no problem if the documents
don't
move.  This whole discussion is about that subset of application that
need
to have the travelling document problem solved.  To reiterate, this
would
include

1) someone putting a copy of some document at a different location
because
the creator of that document decides to update it yet leave it at the
same
URL (e.g. the W3C website, or some page of it).

2) Someone wanting to put multiple signed search results in the same
file.

3) Someone wanting to move a signed resource between being inside versus
outside of a document.

Viewing Location (and encoding) as hints don't solve this problem for
two
reasons.  First, there are times when the encoding has to be applied
after a
transform (e.g. base64 decode after the child::text() Xpath in example 3
above).  Second, you're really saying that a wonderfully simple solution
is
to not address these people's problems with core behavior but instead to
tell them that their problem is too weird and must only be addressed by
their application logic, and that their signatures will not be
verifiable
outside of their own application domain (unless the host application
adds
code to address their specific application).

This seems like an awful mess compared to providing a simple method that
allows these people to solve their problem in a way that will be
understood
by all applications that use this digital signature specification.

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

-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
to
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'
help
the application find the bits that the core code will need to do the
validation.

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

>From an API point of view, proponents of the first idea seem to want to
call
CreateSignature() or VerifySignature() and give a pointer to a Signature
element.  Proponents of the second idea seem to want the same thing,
except
that they must first set up an application-specific callback function
that
CreateSignature() and VerifySignature() can use to help dig up the
required
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
bucket
of bits.  Presumably, when the signer signed, the Location and
Transforms
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
signature.
I agree that it will work in any single application context, but it has
an
unappealing engineering aesthetic.

Finally, when proponents of the second idea say that Transforms are
'hints',
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
the
callback function, must the callback function resolve the Location or
must
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 Monday, 22 November 1999 16:17:58 UTC