W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > January to March 2000

RE: Enveloped signatures and XPath

From: Mark Bartel <mbartel@thistle.ca>
Date: Mon, 27 Mar 2000 15:48:32 -0500
Message-ID: <3C4B400C1E317E4799AAAF2317BDCED1046288@arafel.ealdwood.thistle.ca>
To: "'John Boyer '" <jboyer@PureEdge.com>, Mark Bartel <mbartel@thistle.ca>, "''Joseph M. Reagle Jr. ' '" <reagle@w3.org>
Cc: "'''Petteri Stenius ' ' '" <Petteri.Stenius@remtec.fi>, "'''IETF/W3C XML-DSig WG (E-mail) ' ' '" <w3c-ietf-xmldsig@w3.org>
Hi John,

> Exclusion logic is quite unsecure and therefore useless unless
> appropriate measures have been taken to be quite specific about what
> gets excluded.

In some scenarios, I agree.  That's why I was talking about measures for
being specific.  In non-legal signature scenarios (which I believe will be
the majority), it may or may not matter.  Depends on what the signature is
being used for, and in what context.  Not all signed documents are

My main question is, I receive a document that has a signature with an XPath
transformation.  If I don't recognize the XPath, how do I trust that

Since the single-element-exclusion XPath seems to be one that would be
commonly used, I would think it would simplify matters to create a transform
that does specifically that job, rather than asking applications to
recognize a specific XPath expression that does that task.

-Mark Bartel

-----Original Message-----
From: John Boyer
To: Mark Bartel; 'Joseph M. Reagle Jr. '
Cc: ''Petteri Stenius ' '; ''IETF/W3C XML-DSig WG (E-mail) ' '
Sent: 3/27/2000 1:56 PM
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
BE in the message digest, so if the identified element's content is
then the message digest will break.

Exclusion by id is bad because you identify an element whose content
NOT BE in the message digest, so if the identified element's content,
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
better.  One can identify an element, but then add additional tests that
only exclude the element if it has the right properties, properties
the application author can guarantee do not impact the interpretation of
signature over the material that is digested.

Exclusion logic is quite unsecure and therefore useless unless
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

-----Original Message-----
From: w3c-ietf-xmldsig-request@w3.org
[mailto:w3c-ietf-xmldsig-request@w3.org]On Behalf Of Mark Bartel
Sent: Monday, March 27, 2000 8:10 AM
To: 'Joseph M. Reagle Jr. '
Cc: ''John Boyer ' '; ''Petteri Stenius ' '; ''IETF/W3C XML-DSig WG
(E-mail) ' '
Subject: RE: Enveloped signatures and XPath


Rephrasing my main point, the verifying *application* has to know how
document was transformed in order to know whether the signature signed
whatever it was supposed to.  The signature engine can check whether the
signature is "valid" but can't do that trust evaluation.  So if there is
XPath transform, the application has to look at the XPath to decide
to trust the document.  With our current spec, an application MUST
understand at least that simple XPath expression in order to use an
signature.  While I'm ok with a signature engine needing to know
special XPaths, I'm not comfortable with making that a requirement for
application that wishes to embed a signature.

So when Petteri suggested that we might create a simpler Transform for
simple exclusion, I thought it was a good idea.

Alternatively, the engine could tell the application "this was a simple
exclusion" but that seems less elegant and would be
However, if we want to go this way I think we should have specific text
the draft.

My point about DTDs, Schemas, etc, was just that the application might
to verify that the document is in a certain form (for document closure,
example); you can do that with XPath, but you can also do it in other
If you encounter some XPath in a signature that you're not familiar
the only general way to determine the effect is to examine the output of
transforms... one test that could be done is checking validity against a
format or schema.

Basically I think that having only XPath for exclusion makes it
for an application using this specification to decide trust.  I think we
could make it easier by adding a simpler transform.

-Mark Bartel

-----Original Message-----
From: Joseph M. Reagle Jr.
To: Mark Bartel
Cc: 'John Boyer '; 'Petteri Stenius '; 'IETF/W3C XML-DSig WG (E-mail) '
Sent: 3/26/2000 4:31 AM
Subject: RE: Enveloped signatures and XPath

On Fri, 24 Mar 2000, Mark Bartel wrote:
> kind of document definition?), or it must understand the XPath
> itself, and "know" that the expression is doing the right things.  It
> be much simpler to verify that the exclusion was correct with an IDREF
> exclusion transformation.  "Does the signature itself have the
exclusion id,
> yes or no?"

I'm not exactly sure what you mean by the IDREF exclusion
could you provide an example?

> I would like to see an exclusion mechanism that does not involve
> XPath.  The
> fact that the XPath transform can do anything is precisely the reason
> for wanting a simpler transform that can't.

Which is why last time we discussed this we opted for the generality of
XPath, and a specific well defined instance for excluding
which Petteri rightfully points out we haven't provided yet (though I
think this is a good path), but ...

> The big difference between the XPath approach and the plain link case
> that the verifier is automatically verifying that the document matches
> "document definition" when they evaluate the XPath; they can't do
> else.  In the plain link case, the verifier can choose not to test the
> document against the document definition.

I don't recall if this was part of the previous discussion. Something
would've been nice to put in (and resolve) in the requirements document
was the necessity of validating the signature (in the XML sense): is the
DTD/schema necessary?

Regardless, Mark, if we provide the profiled Xpath instance for removing
SignatureValue, can't you still code your signature application to its
semantic (as you would do with the other solution) without needing the
DTD? (Find some string 'blah' and remove SignatureValue (be it an Xpath
string or something else.)  Or would the result of the XPath process
and the application 'hack' be intrinsically different (or hard to
make similar)?

And is your concern about DTDs with respect to Signature applications
knowing (I doubt this, not too hard to ask Signature applications to
have the DTD/schema around), the fact that whichever XML toolkit you are
using doesn't require them, or the fact that in an Enveloped Signature
(by definition) have content from different namespace, which DTDs don't
easily support?
Received on Monday, 27 March 2000 15:48:42 UTC

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