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

RE: Re: Re: XPath Expression

From: John Boyer <JBoyer@PureEdge.com>
Date: Thu, 2 Aug 2001 09:42:59 -0700
Message-ID: <7874BFCCD289A645B5CE3935769F0B5219639C@tigger.PureEdge.com>
To: "merlin" <merlin@baltimore.ie>, <edsimon@xmlsec.com>
Cc: <reagle@w3.org>, <bdournaee@rsasecurity.com>, <w3c-ietf-xmldsig@w3.org>

Hi all,

Every once in a while I still forget to manually apply the workaround
for the Microsoft Exchange bug that autoconverts my plaintext messages
to HTML (there is no way to permanently set up the fix).  Here it is

XPath transforms do boolean tests, as Merlin pointed out, so that it
would be more convenient, i.e. like an XSLT for-each.

The expression (//. | //@* | //namespace::*) in C14N is only there to
tell you what C14N will do by default if you pass it an octet stream,
and you must achieve the effect by whatever means are at your disposal.
Thus, you can create a compliant implementation of dsig's REQUIRED C14N
even with the problems you are having with Python.

There is no way to give C14N an alternate expression to operate over.
If you want something other than the default behavior, then C14N only
specifies that it receives the logical equivalent of the resulting
node-set, which you can derive by any means you wish.

The place you will run into trouble is in trying to use your Python
implementation in conjunction with an XPath transform containing an
expression that distinguishes attributes from namespaces.  You will not
be able to properly form a node-set based on the expression, but if you
were able to, then C14N would happily canonicalize it for you.  However,
this behavior is RECOMMENDED, not REQUIRED, so you have some 'wiggle'

John Boyer
Senior Product Architect, Software Development
Internet Commerce System (ICS) Team
PureEdge Solutions Inc. 
Trusted Digital Relationships
v: 250-708-8047  f: 250-708-8010
1-888-517-2675   http://www.PureEdge.com <http://www.pureedge.com/>  	

-----Original Message-----
From: merlin [mailto:merlin@baltimore.ie]
Sent: Thursday, August 02, 2001 8:24 AM
To: edsimon@xmlsec.com
Cc: reagle@w3.org; bdournaee@rsasecurity.com; w3c-ietf-xmldsig@w3.org
Subject: Re: Re: Re: XPath Expression 

Hi Ed,

>I'd certainly be keen to see the full working XPath expression if
>wants to take up the challenge.  Merlin's suggestion, by itself, is not
>the whole solution but only part as it returns a boolean, not nodes.  

Blake asked for something to put in an XPath transform;
our XPath transform does a boolean test of each node in
the node set against its expression.

So, you are right; what I suggested is not a general
XPath expression for selecting all of a document but
its URI attributes; XSLT is the tool for that job.
But, it is a suitable test expression for our XPath
transform to perform this task.

I think. (sometimes)


>In general, XPath is good at selecting nodes but was not really
>for removing subnodes.  With current tools, I'd say removing subnodes
>best done with XSLT.
>BTW, the XSLT I've presented below does actually do the trick.
>-- Original Message --
>>I'd guess that something like not ((name() =3D "URI") and
>>might work.
>>>>>This would allow me to change the URI without altering the validity
>>>>If it's being used in the Canonical XML context, remove the '//@*'
>>>>         (//. | //@* | //namespace::*)
>>>Correct me if I'm wrong but wouldn't the above remove ALL attributes,
>>>just the one Blake wants removed.
>>>I'm not sure that there is an XPath solution but the solution in XSLT
>>>look like this:
>>><?xml version=3D"1.0" encoding=3D"UTF-8"?>
>>><xsl:stylesheet version=3D"1.0" 
>>>  xmlns:xsl =3D"http://www.w3.org/1999/XSL/Transform"
>>>  xmlns:xmlsig=3D"http://www.w3.org/2000/09/xmldsig#">
>>><!-- Identity transform -->
>>><xsl:template match=3D"@*|node()">
>>>  <xsl:copy>
>>>    <xsl:apply-templates select=3D"@*|node()"/>
>>>  </xsl:copy>
>>><!-- Skip the Reference/@URI attribute -->
>>><xsl:template match=3D"xmlsig:Reference/@URI" priority=3D"2"/>
>Ed Simon
>XMLsec Inc.
>Interested in XML Security Training and Consulting services?  Visit

Baltimore Technologies plc will not be liable for direct,  special,
or consequential  damages  arising  from  alteration of  the contents of
message by a third party or as a result of any virus being passed on.

In addition, certain Marketing collateral may be added from time to time
promote Baltimore Technologies products, services, Global e-Security or
appearance at trade shows and conferences.

This footnote confirms that this email message has been swept by
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.
Received on Thursday, 2 August 2001 12:43:30 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:21:36 UTC