RE: Enveloped signatures and XPath

     Just incidentally, the examples suggest that the transform normally
applied before calculating the digest will omit the bulk of the current
Signature element except insofar as pulled in by References.  Otherwise,
having Manifest or SignatureProperty explicitly referenced makes little
sense to me (they're already inside the Signature element).  Of course,
both Transforms and CanonicalizationMethod need to be in the digest base,
to avoid the known transform substitution attacks (canonicalization is a
type of limited transform).
     Would it thus be simpler to have the standard transform remove any
Signature element encountered which was not the top-level subject of any
reference (not necessarily one in the current block)?

          Tom Gindin

"John Boyer" <jboyer@PureEdge.com> on 03/29/2000 06:45:25 PM

To:   Tom Gindin/Watson/IBM@IBMUS
cc:   <gregor.karlinger@iaik.at>, "Peter Lipp" <Peter.Lipp@iaik.at>
Subject:  RE: Enveloped signatures and XPath



Hi Tom,

No problem at all.

Suppose we have a signature S2 that signs an element R that is ancestor to
both S2 and a previously completed signature S1.  Further,

<R>

<S1>
     Reference that signs R
     Transform that omits S2 and changeable bits of S1
</S1>

<S2>
     Reference that signs R
     Transform that omits changeable bits of S2
</S2>

</R>

Since both S1 and S2 are within the element that they reference, both are
enveloped (by R).

S1's transform omits S2 because S2 must change after signature S1 is
created.

S1 and S2 omit the parts of themselves that must change while they are
creating themselves.

In other words, part of creating S1 (or S2) is calculating and storing
DigestValue for R and all its descendants.

So, the issue is, since we know that changes will occur within S2 during
the
creation of S2, why not automatically omit S2 from the DigestValue
calculation of any references within S2?

However, S2 points to R which contains S1.  The automatic exclusion, were
it
to be added to our spec, should not omit DigestValue contents from S1,
since
those are not changing during the creation of S2.  What I was getting at is
that S1 is not an ancestor of any DigestValue in S2, so nothing from S1
will
be automatically excluded.

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


-----Original Message-----
From: tgindin@us.ibm.com [mailto:tgindin@us.ibm.com]
Sent: Wednesday, March 29, 2000 12:53 PM
To: John Boyer
Cc: gregor.karlinger@iaik.at; Peter Lipp
Subject: RE: Enveloped signatures and XPath


     Sorry, John.  I doubt that I was the only one misunderstanding the
part of the proposal about "enveloped signatures", though.  If the
Signature element is already complete, excluding it doesn't seem to be
necessary, and how can an incomplete Signature element in another document
be ancestral to the digest value unless both documents reference each
other?
     If these are useful questions rather than ones caused by my lack of
XML knowledge, please feel free to post the response.

          Tom Gindin

"John Boyer" <jboyer@PureEdge.com> on 03/29/2000 02:10:44 PM

To:   Tom Gindin/Watson/IBM@IBMUS, <gregor.karlinger@iaik.at>
cc:   "Peter Lipp" <Peter.Lipp@iaik.at>, "''IETF/W3C XML-DSig WG \(E-mail\)
      ' '" <w3c-ietf-xmldsig@w3.org>
Subject:  RE: Enveloped signatures and XPath



Hi Tom,

The proposal is only to exclude Signature elements that are ancestor to the
DigestValue element whose content is being calculated.  This does not
impact
one's ability to sign someone else's signature.

However, I'm sure this has been asked and answered negatively in the past.

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 tgindin@us.ibm.com
Sent: Wednesday, March 29, 2000 10:57 AM
To: gregor.karlinger@iaik.at
Cc: Peter Lipp; ''IETF/W3C XML-DSig WG (E-mail) ' '
Subject: RE: Enveloped signatures and XPath


     Is the proposal here that all elements within a <Signature> should be
excluded unless they are the objects of a Reference?  If so, how would a
subsequent signer include the KeyInfo or SignatureValue from an enveloped
signature unless the original signer had attached an ID to them?

          Tom Gindin

Received on Wednesday, 29 March 2000 19:10:09 UTC