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 18:43:55 UTC