RE: Comments on new XPath Filtering proposal

Hi Gregor,

-----Original Message-----
From: w3c-ietf-xmldsig-request@w3.org
[mailto:w3c-ietf-xmldsig-request@w3.org]On Behalf Of Gregor Karlinger
Sent: Monday, March 27, 2000 3:14 AM
To: John Boyer; IETF/W3C XML-DSig WG (E-mail)
Subject: Comments on new XPath Filtering proposal


John,

please find my comments on your latest proposal for the XPath Filtering
section attached to the corresponding sections below. As I am not an
XPath expert, please be patient with some of my questions ;-)

<john>No sweat</john>

> -----Original Message-----
> From: w3c-ietf-xmldsig-request@w3.org
> [mailto:w3c-ietf-xmldsig-request@w3.org]On Behalf Of John Boyer
> Sent: Friday, March 24, 2000 1:15 AM
> To: IETF/W3C XML-DSig WG (E-mail)
> Cc: Martin J. Duerst; James Clark; Joseph Reagle; Eastlake
> Donald-LDE008; TAMURA Kent; Christopher R. Maden; Jonathan Marsh; Ed
> Simon
> Subject: RE: Enveloped signatures and XPath
> Executive overview
> ==================

[...]

> <p>Based on the expression evaluation requirements of the XPath function
> library,
> the <b>document order</b> position of each node must be available in the
> parse tree,

How can I achive this with a standard DOM parser?

<john>
The issue does not seem to be how you do this with a standard DOM parser.
The issue seems to be can you do it with the parser that is attached to any
working XPath engine.  The parser must construct a node-set capable of being
passed as part of the XPath evaluation context.  The XPath engine seems to
require certain things (like the maintenance of document order for the
position() function and the maintenance of namespace prefixes for lookup in
the initial namespace context).
Since XPath evaluation requires these things, any parser attached to an
XPath engine will support them.
</john>

[...]

> <h4>6.6.3.3 XPath Transform Functions</h4>
>
> <p>The function library of the XPath transform includes all functions
> defined
> by the XPath specification plus the serialize() function defined
> below.  For most XPath transforms, serialize() need not be called
> explicitly
> since it is called automatically if the expression result is a node-set.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  Who makes this call? The XPath engine? How would the XPath engine
  behave if the serialize function was not defined?

<john>
The XPath transform itself makes the call.  The pseudocode is something like
this:

char *XPathTransform(char *theInput, node* ExprNode)
{
	nodeSet *theRoot = XPathEngine.Parse(theInput);
	context *theContext = XPathEngine.MakeContext(ExprNode->namespace,
theRoot);

	void *result;
	int resultType;
	String serializedResult;
	char *theOutput;

	result = XPathEngine.eval(theContext, ExprNode->text, &resultType);

	switch (resultType)
	{
		case boolean:
		case number : serializedResult = XPathEngine.f("string", result); break;
		case nodeset: serializedResult = XPathEngine.f("serialize", result);
break;
	}

	theOutput = UTF8encode(serializedResult);
	return theOutput;
}
</john>

[...]

> <h4 name="sec-XPathTransformOutput">6.6.3.4 XPath Transform Output</h4>
>
> <p>The result of the XPath expression is a string, boolean, number, or
> node-set.
> If the result of the XPath expression is a string, then the
> string converted
> to
> UTF-8 is the output of the XPath transform. If the result is a boolean or
> number,
> then the XPath transform output is computed by calling the XPath string()
> function
> on the boolean or number then converting to UTF-8.
> If the result of the XPath expression is a node-set, then the XPath
> transform
> result is computed by applying the serialize() function to the node-set,
> then
> converting the resulting string to UTF-8.</p>

Again, is this call to the serialize() function made automatically by the
XPath engine?

I deduce the following tasks for the output transformation
from the assertions made so far, depending on the XPath expression's result:

* If result is a string, convert it to UTF-8

* If result is boolean/number, explicitely call the XPath string() function
  and then convert its result to UTF-8

* If result is a node set, the actual result of the XPath processing is
  already a string, which must be finally converted to UTF-8

Am I right?

<john>
Almost.  As I pointed out above, if the XPath result is a node-set, then the
result is a node-set, not a string.  The XPath transform will convert it to
a string.
</john>

[...]

>The node test
> returns true for all
> nodes except the <code>SignatureValue</code> and
> <code>KeyInfo</code> child
> elements and the
> and the <code>DigestValue</code> descendants of <code>Signature</code> S1.

Why omitting KeyInfo? I think this is a little bit confusing here since
KeyInfo can be made available before computing the Reference's digest.

<john>
True that the KeyInfo 'can be' assigned before computing DigestValue.
However, I cannot recall anywhere in the spec  that says that
implementations must assign KeyInfo before computing DigestValue.  Perhaps I
missed it (please point it out as I would be happier if it were there), and
if it isn't there, then perhaps it should be.  Once it is, then you are
right that KeyInfo need not be omitted.

I omitted KeyInfo because of the possibility that DigestValue could be
computed beforehand.  By leaving it out, my example works regardless of how
the spec is written.  Note that it does no harm to leave out the KeyInfo
since it will be signed by the SignatureValue.

John Boyer
Software Development Manager
PureEdge Solutions, Inc. (formerly UWI.Com)
Creating Binding E-Commerce
jboyer@PureEdge.com

</john>

Regards, Gregor
---------------------------------------------------------------
Gregor Karlinger
mailto://gregor.karlinger@iaik.at
http://www.iaik.at
Phone +43 316 873 5541
Institute for Applied Information Processing and Communications
Austria
---------------------------------------------------------------

Received on Monday, 27 March 2000 14:12:59 UTC