RE: Enveloped signatures and XPath

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
contracts.

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
document?

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
JetForm

-----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
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


-----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


Joseph,

Rephrasing my main point, the verifying *application* has to know how
the
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
an
XPath transform, the application has to look at the XPath to decide
whether
to trust the document.  With our current spec, an application MUST
understand at least that simple XPath expression in order to use an
embedded
signature.  While I'm ok with a signature engine needing to know
specific
special XPaths, I'm not comfortable with making that a requirement for
any
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
implementation-specific.
However, if we want to go this way I think we should have specific text
in
the draft.

My point about DTDs, Schemas, etc, was just that the application might
want
to verify that the document is in a certain form (for document closure,
for
example); you can do that with XPath, but you can also do it in other
ways.
If you encounter some XPath in a signature that you're not familiar
with,
the only general way to determine the effect is to examine the output of
the
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
complicated
for an application using this specification to decide trust.  I think we
could make it easier by adding a simpler transform.

-Mark Bartel
JetForm

-----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
expression
> itself, and "know" that the expression is doing the right things.  It
would
> 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
transformation,
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
SignatureValue,
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
is
> that the verifier is automatically verifying that the document matches
the
> "document definition" when they evaluate the XPath; they can't do
anything
> 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
that
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
not
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
you
(by definition) have content from different namespace, which DTDs don't
easily support?

Received on Monday, 27 March 2000 15:48:42 UTC