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 13:54:39 UTC