RE: Enveloped signatures and XPath

Hi Gregor,

As I said in a prior email, I personally agree with automatic exclusion from
the DigestValue calculation of any signature element that will be ancestor
of the DigestValue.  This is what we did in XFDL since there seemed to be
little point in making everyone write the exclusion logic every time (all
signatures in XFDL are enveloped because the form is always the root).

The group previously discussed this, albeit briefly, and decided against.
There may be some minutes or archive feedback reflecting this, or it may not
have been recorded.

However, I am not willing to take a strong position on this because I think
that it is not hard for one's application to recognize a specific expression
*constructed by the application designer* to exclude the signature element
from the DigestValue calculation.  Thus, the application will function
without full XPath support, and will express its signatures in a way that
can be understood by other applications.  But if you want write a generic
piece of code that understands everyone's signatures, you are pretty much
required to implement the XPath transform, in which case the specific
expressions used by various applications will be supported by your generic
program.

I believe this is the reason why the group did not want to make th exception
you are recommending.

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

<Peter>
  A question here: Why can't we simply exclude the entire Signature element?
  That's what Gregor and I have been discussing today. I would strongly
prefer
  that! I'd like to know if anything spoke against it.....
</Peter>

<John>
  > Sorry Peter, but that's not an accurate paraphrase.  It is quite
important
  > to be able to exclude certain elements, but that one requires a great
deal
  > of precision in identifying what must be excluded to ensure that you are
  > excluding what you meant to exclude.
  >
  > Exclusion by id excludes an element based on the value of a single
  > attribute, and this is not enough in most cases to accurately identify
the
  > information to be excluded, and to restrict one's exclusion to only that
  > information.
</John>

I will try to phrase more accurately than Peter ;-):

If an enveloped signature is to be constructed, then there obviously the
following problem occurs: One has to take care that (at least) tholse parts
of the Signature element are omitted which are not available at the time of
computing the reference's digest, which are the SignatureValue and the
DigestValue of the reference currently worked on.

The main point of my discussion with Peter yesterday was: What important
case
could be out there in the world that one cannot simply omit the Signature
element as a whole in such a case of an enveloped signature?

If there exist important data entities inside the Signature element that
should also be signed, why not simply add another references directly to
that items?

Neither Peter nor I are argueing against the XPath transform in general, but
I
feel that the spec should be kept as simple as possible if we don't buy
severe restrictions with such simplicity. And in my opinion omitting the
whole
Signature element does not lead to any restrictions.

Regards, Gregor
---------------------------------------------------------------
Gregor Karlinger
mailto://gregor.karlinger@iaik.at
http://www.iaik.at
Phone +43 316 873 5541
Institute for Applied Information Processing and Communications
Austria
---------------------------------------------------------------

Received on Wednesday, 29 March 2000 13:03:35 UTC