RE: Con Call and XPointer/XPath

As the author of the IOTP spec, I've been watching this WG closely but not
participating very actively since there are better experts than I on digital
signatures out there. However I want to reinforce John's point that a method
of pointing to fragments of XML documents for digital signature purposes IS
a requirement for IOTP and therefore IMOH, MUST be included within scope.

IOTP's needs are simpler than John's in that all we need to be able to do is
refer to a number of XML elements (and their children) that need to be
digitally signed in a Manifest. Using the ID attribute with Xpointer would
be ideal for this.

The current version of IOTP doesn't use Xpointer because it wasn't around
when the spec was written. However I do anticipate that Xpointer will be
used in a future version although probably it would be OK to just require a
subset of it.

If this WG doesn't include Xpointer within it's scope (or something very
similar) then future IOTP specs will have to add it before the digital
signature spec will be usable.

Regards

David

-----Original Message-----
From: John Boyer [mailto:jboyer@uwi.com]
Sent: Thursday, September 09, 1999 2:37 PM
To: w3c-ietf-xmldsig@w3.org
Subject: Re: Con Call and XPointer/XPath


It's too bad I missed much of this (9sep99) con call as it seems there was
some consensus building on punting Xptr out of the core syntax and/or making
it optional, and these possible decisions concern me greatly for the
following reasons:

Summary
=======
1) Requirements, by definition, are not optional
2) Bad optics for W3C
3) Bad optics for DSig WG
4) XPointer is NOT TIED TO DOM
5) XPointer/XPath provides easy syntax for specifying partial documents
	esp. for saying what *not* to sign as opposed to saying what to sign
6) Simplified subset of XPath can solve all problems.

Details
=======
1) We should not relegate XPointer support to the manifest only, nor should
we make XPointer 'optional' in the core syntax.  The reason is that we have
a *requirement* to sign partial documents, and we have an implicit
*requirement* to create secure digital signatures.  Requirements, by
definition, are not optional.

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
standards works such as DSig, esp. when at least one WG participant has
shown a clear and as yet unrefuted need for (something like) the former
standard in order to meet the requirements of the latter.  What is the point
of building the former spec if it is far too complicated (whick I don't
believe), and what is the point of building the latter spec if it cannot
adequately address the problem space (which I still maintain it cannot do
without requirement for XPointer)?

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.

4) Contrary to a con call assertion made before I joined the call (at the
end), XPointer is NOT TIED TO DOM.  DOM is only mentioned in Xptr to state
that the 'range' command is like the one in DOM; interestingly we do not
seem to need the range command or anything specific to Xptr, so the mention
of DOM is irrelevant.  DOM is only mentioned in XPath to explain why some
axis has a particular name.  Nowhere does it state that XPtr and XPath are
tied to anything but the XML 1.0 spec, to which all XML parsers must comply.

Naturally, some form of XML parser will come into the picture here because
you need it in order to make heads or tails of ANY partial document
processing scheme.  For example, you cannot select objects by URI fragment
without parsing the document enough to find the elements indicated by the
fragment ID (and also figuring out which attribute is supposed to represent
the ID in the first place).

XPtr is just a syntax for describing how to filter a document.  With a
simple BNF rewrite rule, one can construct a hand-built recursive descent
parser to recognize the XPtr syntax, so a recognizer can be built by a
language newcomer despite the left associativity of boolean operators.  Once
you can parse the Xptr itself, how you choose to apply it to the document
depends strictly on the rules of XML 1.0 plus whatever you've been passed by
the previous transform step of the digital signature transformation
sequence.

5) Xptr (or some subset of it) can be easily be used to indicate the
portions of the document that must be signed.  More importantly, Xptr
provides an easy syntax for describing which portions of the document should
*not* be signed.  This is very important since it is useful in the creation
of secure signatures to have the message M that is actually signed *be* a
full XML document including all 'ancestor' information for the elements of
interest, including the encoding information, the DTD, the tags and
attributes of all ancestor elements, the order of sibling elements and even
PIs and comments if necessary to a particular signature (e.g. to sign code
expressed in XML).

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).

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

Received on Thursday, 9 September 1999 17:59:45 UTC