RE: Enveloped signatures and XPath

I worry that it might be confusing to have a new transform with XPath in the
name.  I have no problem with the spec saying "this Transform is equivalent
to an XPath Transform with the expression '...'".

How about (as a discussion point):

6.6.5 Element Exclusion

Identifier: 
    http://www.w3.org/2000/02/xmldsig#exclude-element

This Transform contains a single parameter child element called Id.  The
content of the Id element is the id of the element to be excluded.  This
transform is equivalent to the following XPath Transform:

  [some XPath transform]

-Mark Bartel
JetForm

-----Original Message-----
From: Petteri Stenius
To: 'John Boyer'; Mark Bartel
Cc: ''IETF/W3C XML-DSig WG (E-mail) ' '
Sent: 3/27/2000 4:56 PM
Subject: RE: Enveloped signatures and XPath


John,

I agree with you that it is possible to make more specific inclusion (or
exclusion) transforms with XPath.

But what you are also saying is that it's possible to compose not so
specific transforms with XPath. How does the verifying application know
that
a given XPath expression is good enough to trust? Should the verifier
simply
trust the signer? This requirement for trust is what I guess Mark is
also
trying to point out.

Exclusion by id only solves the most simple case with enveloped
signatures,
and as such is rather restricted. 

Mark suggests that we should define a new transform, and I agree with
that. 

I'd take this a little bit further by defining the new transform using
the
existing algorithms (XPath or XSLT) and by identifying the transform
with a
URI reference. For example

<Reference URI="">
	<Transforms>
		<Transform
Algorithm="&dsig;xpath:exclude-the-signaturevalue-element"/>
	</Transforms>
</Reference>

The XML Signatures spec would include the XPath expression for this
named
transform, the expression does not need to be included with the
signature.

The signature verifier easilly identifies this transform and can choose
to
use the XPath expression, or have the functionality programmed into the
implementation. 


Petteri


> -----Original Message-----
> From: John Boyer [mailto:jboyer@PureEdge.com]
> Sent: 27. maaliskuuta 2000 21:57
> To: Mark Bartel; 'Joseph M. Reagle Jr. '
> Cc: ''Petteri Stenius ' '; ''IETF/W3C XML-DSig WG (E-mail) ' '
> Subject: RE: Enveloped signatures and XPath
> 
> 
> Hi Mark,
> 
> Actually, I will maintain that exclusion by id only is a bad idea
> 
> Inclusion by id is useful because you identify an element 
> whose content WILL
> BE in the message digest, so if the identified element's 
> content is changed,
> then the message digest will break.
> 
> Exclusion by id is bad because you identify an element whose 
> content WILL
> NOT BE in the message digest, so if the identified element's 
> content, tag,
> attributes, etc. are changed, then the message digest will not break.
> 
> The purpose of doing exclusion logic with XPath is that, 
> although it is
> possible to do exclusion by id with XPath, it is also 
> possible to do much
> better.  One can identify an element, but then add additional 
> tests that
> only exclude the element if it has the right properties, 
> properties which
> the application author can guarantee do not impact the 
> interpretation of the
> signature over the material that is digested.
> 
> Exclusion logic is quite unsecure and therefore useless 
> unless appropriate
> measures have been taken to be quite specific about what gets 
> excluded.
> 
> John Boyer
> Software Development Manager
> PureEdge Solutions, Inc. (formerly UWI.Com)
> Creating Binding E-Commerce
> jboyer@PureEdge.com
>

Received on Tuesday, 28 March 2000 11:11:35 UTC