RE: Simplified Syntax

Hi Joseph,

(Also Dave, this contains yet another description of why I like XPath, which
you asked that I explain again at some point).

I'm glad you had a look at the simplified syntax.  I really don't mind
whether we simplify or whether we move forward with what we have and solve
the Location problem in some way.

As for the XSLT transform, you could make it optional or preferably take it
out.  I didn't suggest the need for it.  I only needed XPath so I would have
a precision language for describing what was omitted from the digested
content.  However, it seemed to me that people other than me wanted to do
some very application specific things like compress/decompress, so I threw
in the idea of a Java-based transform.  Once you do that, though, the idea
of an XSLT is certainly no scarier.

I've been putting this off as long as possible for fear that XPath would be
thrown out of the spec, but part of the problem is that I don't agree with
Tim BL (entirely).  I agree that we are indeed signing only the bits that
get digested.  However, I don't agree that nothing can be said about the
original document before the transforms.

The whole idea behind document closure is that an XPath transform contains
an 'assertion' that only certain very precisely defined changes can be made
to the pretransformed document without breaking the signature.  The
permissible changes can undergo a security review within the application
context, the result of which would be the agreement of the reviewer(s) that
such changes could not materially affect the signer's signature.  Obviously,
if an attacker modifies the bits directly covered by the digest, then the
signature breaks.  But, if the attacker modifies regions of the document not
originally signed by the user, but they are modified in ways that violate
the conditions established by the XPath, then the modifications will be
added to the digestible message during verification, which will also break
the signature.

In other words, if an attacker were to modify the document in a way that is
not permitted by the (signed) XPath transform in the ObjectReference, then
the signature would still break because the wrong message would be
constructed for comparison to the DigestValue.

So, the XPath can indeed protect the entire document from unwanted
modifications despite the fact that it drops out certain pieces.  When we
verify, start with a document, and apply the XPath transform.  If the
signature validates, then two assertions can be made: 1) the document
contains all the bits it used to contain, PLUS 2) the document as a whole
has not been modified in ways contrary to the precise definitions given in
the XPath.  This is the essence of how XFDL signatures work, only there was
no XPath at the time, so we created our own syntax (it is specific to XFDL
parse trees, whereas we now require XPath because we want to do the same
idea only on generic XML documents).

Thus, my interpretation of ObjectReference is quite different from yours.
The information in ObjectReference that allows me to arrive at the bag of
bits covered by the DigestValue is quite important to achieving document
closure.  It is quite necessary that it have well-defined processing rules
and that it be signed by the SignatureValue (except that sometimes people
might want to omit a very specific transform like the base 64 decoder).

As for reliance on XPath in the 'simplified' proposal, it would require only
a slight tweak in order for me to say that every instance of XPath in the
simplified proposal would require an XPath in our current spec.  The only
thing I did was took out the idea of multiple element references.  XPath
easily allows you to list multiple elements, so there is no need for us to
invent our own separate syntax (except of course that people don't want to
use the W3C recommended XPath syntax).

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 Joseph M. Reagle
Jr.
Sent: Tuesday, November 23, 1999 3:44 PM
To: John Boyer
Cc: Donald E. Eastlake 3rd; Dave Solo; DSig Group
Subject: Re: Simplified Syntax


At 10:45 99/11/20 -0800, John Boyer wrote:
 >I would like to ask you to consider at length the merits of completely
 >throwing out any notion that core behavior should dig up resources
external
 >to the document containing the Signature element.  The proposal below
 >basically takes what we have now and throws out all of the stuff that most
 >people really dislike, so it is not terribly different from what we have
 >now.

This conversation has been useful to me in that a number of things are
clearer in my own head, which is a good thing! Two responses follow, one in
a chair capacity and one in a technical capacity.

Chair: There doesn't seem to be strong support  for change on the list so
far. I think this is mainly for two reasons (1) people aren't keen to change
what we have now and (2) in your proposal it relies upon XPath.
Procedurally, David has said he will work on another rev that the editors
will post next week and it will hopefully speak more clearly on these
issues. At that point we can take a consensus poll in terms of moving
forward and document any minority positions.

Technical: The one thing I like in your proposal is the clarity between the
signature core (cryptographically validating bytes) and manifests. As I
originally envisioned our design, the "core behavior" would do nothing more
than worry about signature (cryptographic) validity. We would also define a
manifest for resources and their content's digests. If we did a good enough
job in defining the manifest semantics we could require Signature
applications to be aware of those semantics! (I knew doing a good job on
that topic would be hard and I think we've seen that it is!) Whether we
called it SignedInfo (and included two other pieces of information) or
occurred within or without the Signature was immaterial in my mind.

What I hope we can do is make a few minimal changes so as to restore this
distinction between a bucket of bits and manifest/reference semantics. An
easy way to do this I think would be to introduce an element within
SignedInfo in which you can place arbitrary data; this might include a set
of ObjectReferences or not. However, I'm not sure I've convinced others this
is a useful thing.

Finally, I feel I've learned the following about ObjectReferences. People
should feel free to tell me if they agree or disagree with any of these
specific points:

1. A digest (and subsequent signature) is over bits. How you get those bits
is immaterial to the digest.
2. Since the "critical bits" of the DigestContent (the stuff digested) is
often not explicitly represented, it is useful to document the way in which
they were derived -- that specification might even permit multiple ways (the
URI is dynamically dereferenced, more than one XML instance transforms into
the final XML instance that is digested, etc.). However this information has
no necessary meaning to the DigestValue itself -- the question is whether
the final value is the same.
2.1 Consequently, my earlier thinking of starting with a source document,
and putting it through various transformations (and achieving closure)
starts at the wrong end of the stick. As TimBL stated when we started
worrying about transforms and context, you are signing the derived content.
3. WE define what our syntax means. We are not "changing its meaning under
the covers." We have to explicitly define the meaning of every bit of syntax
we have. This is why I like to think in terms of assertions with a subject,
predicate and object. I think it is a good idea to say the presence of a
Transforms and a Location element means:
a. There is a set of XML documents that when transformed yield DigestContent
(the content that is finally digested.)
b. At some point in time, the XML document obtained by dereferencing this
URI was just such a document.

BTW: I'm not quite sure why you feel the current spec required XSLT, merely
one of many possible transform algorithms and one I think we should optional
in section 5.1 given it is still a WD (and XPath is now a REC).

_________________________________________________________
Joseph Reagle Jr.
Policy Analyst           mailto:reagle@w3.org
XML-Signature Co-Chair   http://www.w3.org/People/Reagle/

Received on Tuesday, 23 November 1999 20:04:45 UTC