RE: Enveloped signatures and XPath

Automatic exclusion is certainly how we did it in XFDL because we did not
want to use up the expressiveness of signature filters with something that
would happen on every enveloped signature (which is the only kind in XFDL).

It does not seem hard to identify that which will change as the result of
signature creation and specify automatic exclusion of these elements.
However, I do believe that this issue has been raised and rejected at some
prior point in the history of this WG.  Perhaps a search of the archives is
warranted.

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


-----Original Message-----
From: Petteri Stenius [mailto:Petteri.Stenius@remtec.fi]
Sent: Tuesday, March 28, 2000 8:39 AM
To: 'Mark Bartel'; Petteri Stenius; ''John Boyer' '
Cc: '''IETF/W3C XML-DSig WG (E-mail) ' ' '
Subject: RE: Enveloped signatures and XPath



Yes, this is good. We could add some text about the intention and motivation
of the exclude-element transform, like:

"The element exclusion transform is intended to support enveloped signatures
(only?) and SHOULD (or MUST?) be used by implementations when creating
enveloped signatures. The transform excludes the SignatureValue and
DigestValue elements from digest calculation."

A question here: Why can't we simply exclude the entire Signature element?
Are not all the important elements from the Signature element already
included in the digest used for the SignatureValue? Are the detached or
enveloping signatures weaker in security because they do not include the
Signature element?


Petteri


> -----Original Message-----
> From: Mark Bartel [mailto:mbartel@thistle.ca]
> Sent: Tuesday, March 28, 2000 7:11 PM
> To: 'Petteri Stenius '; ''John Boyer' '
> Cc: '''IETF/W3C XML-DSig WG (E-mail) ' ' '
> Subject: 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 12:08:34 UTC