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

RE: Con Call and XPointer/XPath

From: John Boyer <jboyer@uwi.com>
Date: Tue, 14 Sep 1999 09:30:03 -0700
To: "Joseph M. Reagle Jr." <reagle@w3.org>
Cc: <w3c-ietf-xmldsig@w3.org>, "Dan Connolly" <connolly@w3.org>
Message-ID: <NDBBLAOMJKOFPMBCHJOIOECPCBAA.jboyer@uwi.com>
<Joseph>
We also have a requirement to fit the following dead-lines if possible:

        Nov 99 XML Signature Syntax and Processing document to
        Last Call for Proposed Recommendation / Proposed Standard RFC

        Dec 99 Signature Semantics document to Last Call for
        NOTE / Informational RFC

        http://www.w3.org/Signature/charter-19990624.html

If successful, the core syntax might even match or come in under XPtr in
terms of time. Regardless, I am not dismissing the requirement that our
deliverables permit selective signing. However, I don't think that is the
same as saying it is a mandatory to implement for all "core syntax"
applications. If it happens great, but I think we should err on the side of
timeliness. Given the "signature semantics" document has become the
"manifest/package" document in my mind, it will also be a standards track
document, though probably a bit slower.
</Joseph>

<John>
The RD says that partial document is a requirement, and an implied
requirement is security, but since we also have certain timeline
requirements, so what you're saying is that some of the requirements will
not be required in order to meet the timelines.  We could do partial
document, but not with high security, or we could do high security, but drop
partial document, or we could do both but possibly at the cost of the
timeline.
</John>

 >2) The optics for the W3C as a standards body are poor when a W3C work
such
 >as XPointer is dismissed as being too complicated for use in other W3C

I don't know what "optics" means, but the two issues here are (1) timeliness
and spec dependency immaturity and (2) application requirements regarding
processing/memory requirements. It is not stated in the RD, but people have
stated they may do signatures in a smart-card type form factor. Again, it
isn't in the RD, so I don't feel too constrained by it, but I'm always for
defaulting to simplicity and being shown it can be easily done

<John>
The entire Clark parser is not more than 50K compiled.  In fact, the XML
parser combined with the XFDL parse tree builder and XFDL cannonicalizer
together are 104K.  This should be able to fit, even in smartcard and other
small appliance scenarios.
Once you have the parser, writing something that parses through a message,
streaming parts that match a filter to the hash algorithm does not take much
more work.
The only constraint that I can think of is that we might want to limit
ourselve to taking ancestors but perhaps not querying siblings (and hence
other descendants) that are not on a path between the current element and
the root of the tree.  This would allow a simple stack to be used to
represent the current document context.
We are talking about limiting some forms of XML, but perhaps it represents
an acceptable compromise.
Note that I'm still talking about scanning the whole document, and having
lots of siblings and descendants included in the signature.  I'm just
talking about constraining the types of tests that can be written.  For
example, one decide whether to include an element based on a test of
attributes, tag names, etc. of one's grandfather element, but perhaps it is
overkill to have the ability to test the grandfather's second older
brother's fourth son.
</John>

 >3) Also as a matter of optics, the DSig WG cannot be perceived as not
 >wanting to require enough code to create truly secure XML signatures, esp.
 >when we are talking about whether to implement such well known constructs
as
 >boolean logical operators and comparators as the basis of filtering
 >elements.

I've been arguing that this requirement be removed from implementation in
the core syntax until it can be demonstrated that it can be advanced at the
same rate as the rest of that spec. I am now quite convinced that the best
way to meet the requirement (wherever and whenever) is with XPtr.

<John>
Right, this is what I'm saying doesn't have good optics (BTW, this misuse of
the term is borrowed from those executive types who refer to how a situation
will look for the organization).
Why remove it when it can be demonstrated that we simply need a way to
process and, or and not logic, and keep track of where in a tree we are, all
of which are similar to algorithms studied in second or third semester data
structures.  We all do the little infix math processors and trees at around
that time.
</John>

 >4) Contrary to a con call assertion made before I joined the call (at the
 >end), XPointer is NOT TIED TO DOM.

Agreed in principle:

   6. Conformance
   A string conforms to XPointer if it adheres to the syntactic
   requirements imposed by this specification (including that part of
   XPath included by reference). Note that this does not require that the
   string, in association with a URI, actually point to a resource that
   exists at any given moment.

   http://www.w3.org/TR/WD-xptr

But still not sure. In speaking with Dan Connolly, he seemed to agree that
the implicit InfoSet c14n was unavoidable, but understood your point and
raised the example of:

        <!DOCTYPE root [ <!ENTITY anElt "<e/>"> ]>
<root>&anElt;&anElt;&anElt;</root>

        And an xpointer that picks the second child of the root element.
        What sequence of bytes does that correspond to from the input?

In investigating which spec defines what is returned to a client when an
Xlink+XPtr is invoked, I end up with

        5.3.1 / (root) Locates the entire resource; not the document
element, but the
        parent which is over it as well as any adjacent processing
instructions and/or
        other nodes permitted by XML.

        http://www.w3.org/1999/07/WD-xptr-19990709


        infoset: 2.1. The Document Information Item
        There is always one document information item in the information
set, and
        all other information items are related to the document information
item, either
        directly or indirectly.

        http://www.w3.org/TR/1999/WD-xml-infoset-19990517

So I'm still not quite sure if this is well
understood/defined/specified/standardized such that it be an integral part
of XML signature at this time. I'd be interested in your answer to the
question, or for Dan to comment further.

<John>
Firstly, I used root in my example because I wanted to capture all of that
material outside of the root element of the document.  I happen to like
being able to sign that stuff since an application might have a use for
making sure it doesn't change.

Secondly, I think it is fairly well understood.  XPath doesn't come out and
say so because I think they assumed it was obvious, but the entity refs
should obviously be resolved during the parsing of the document, so the
xpointer would refer to the second <e/>.

As far as I know, even the non-validating parsers have to read the DTD and
do this during input, so anything you do to find the portion of the document
you want is going to resolve entity refs.
</John>

 >6) Even if the whole of Xptr is more than is necessary, it should be
 >possible for us to mete out a subset that can still accomplish what is
 >required.  For instance, we do not need anything in Xptr itself, but
rather
 >some of the contents of XPath.  Further, we could consider throwing out
 >recognition of syntactic variations (the syntax sugar, so to speak).

Meaning we'd have

1. the x-path relative axes: {child, descendent, descendent-or-self, parent,
ancestor, ancestor-or-self, preceding-sibling, following-sibling, preceding,
following, self, attribute}
2. the x-path code tests: {Qnames, text(), comment(), pi()}
3. the x-path positional tests: {position, last, <,>}

but not

1. the x-ptr axes: {range, string}
2. the x-ptr absolute location paths: {/(root), id, here, origin}

<John>
Minor point first, I'm pretty sure you can do root in XPath.

Second, I'd agree with throwing out all XPtr-specific functions and sticking
to XPath, which seems to be able to express everything needed.

Third, if we were to constrain the syntax so that a stack could be used to
represent the context at any point in the parse, then you could throw out
all of the axes except self, ancestor, ancestor-or-self, and parent.  Note
that the XFDL/XPtr example I gave only used /descendant-or-self to indicate
the need to test the whole document.  The axis could be constrained to that
particular usage.

John Boyer
Software Development Manager
UWI.Com -- The Internet Forms Company
</John>
_________________________________________________________
Joseph Reagle Jr.
Policy Analyst           mailto:reagle@w3.org
XML-Signature Co-Chair   http://w3.org/People/Reagle/
Received on Tuesday, 14 September 1999 12:31:55 GMT

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