RE: Enveloped signatures and XPath

<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 02:16:59 UTC