RE: Enveloped signatures and XPath

Hi Joseph,

-----Original Message-----
From: w3c-ietf-xmldsig-request@w3.org
[mailto:w3c-ietf-xmldsig-request@w3.org]On Behalf Of Joseph M. Reagle
Jr.
Sent: Sunday, March 26, 2000 11:49 PM
To: John Boyer
Cc: IETF/W3C XML-DSig WG (E-mail)
Subject: RE: Enveloped signatures and XPath



On Thu, 23 Mar 2000, John Boyer wrote:
> Attached and Pasted below is the HTML for a new version of the XPath
http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2000JanMar/att-0250/01-
transforms2.htm

Thanks John, looking good (I look forward to others' comments)

<john>Thanks.  The changes are based on others' comments, so hopefully the
feedback will be more positive</john>

, brief
comments following:

>Identifier:
>http://www.w3.org/TR/1999/REC-xpath-19991116

I think we should move  this identifier to our own namspace since we
specify something above and beyond.

<john>Actually, I've taken great care to only extend the functionality of
XPath in ways that are permitted by XPath.  Addition to the function library
is permitted by applications of XPath.  The end result is that the XPath
transform is an application of XPath, not something above and beyond it.
Hence, sticking to the XPath recommendation URI should be exactly what we
do.  Furthermore, if there are updated versions of XPath in the future, we
can use the differing URI to distinguish the type of expression.</john>

>(The XPath transform cannot simply
>generate incorrect output since many applications distinguish an
>unverifiable signature from an invalid signature).

We don't mention exception handling elsewhere in the spec (which is more
protocol orientated), we should probably add some explanatory text about
this (perhaps including a definition for 'unverifiable'.)

<john>Ah, that is true, and also something I thought might change.
Basically, there are other areas besides the XPath transform that should
throw exceptions.  For example, suppose there is a Java version of XML Dsig
software that does not, by default, contain access to RSA algorithms.  If an
XML signature were encountered that was based on RSA, the java
implementation should throw an exception to indicate algorithm
non-availability (as opposed to claiming that the signature is invalid).
</john>

>As a result of reading the input with an XML processor, linefeeds are
>normalized, attribute values are normalized, CDATA
>sections are replaced by their content, and entity references are
>recursively replaced by substitution text. In addition,
>consecutive characters are grouped into a single text node.
>The XPath implementation is expected to convert the information in the
>input XML document and the XPath expression string
>to the character domain prior to making any comparisons such that the
>result of evaluating the expression is equivalent
>regardless of the initial encoding of the input XML document and XPath
>expression.

Do we need to recommend that Canonical XML transform be used before
the Xpath? (Or do we assume the processors use Canonical XML (or some
other  method (e.g., DOM)) consistently to accomplish this?)

<john>
I don't think we need to recommend using c14n before Xpath.  According to
Tamura Kent, it doesn't do any good anyway.  According to the XPath spec,
all expression evaluation occurs based on UCS code point values, so
everything is supposedly transformed to the 'character domain'
automatically.

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

</john>

>The method of text generation is dependent on the node type and given in
>the following list:

(typo)

Received on Monday, 27 March 2000 14:29:58 UTC