RE: Enveloped signatures and XPath

Hi Joseph,

-----Original Message-----
From: w3c-ietf-xmldsig-request@w3.org
[mailto:w3c-ietf-xmldsig-request@w3.org]On Behalf Of Joseph M. Reagle
Jr.
Sent: Monday, March 27, 2000 12:17 AM
To: John Boyer
Cc: w3c-ietf-xmldsig@w3.org
Subject: RE: Enveloped signatures and XPath


[woops, didn't finish]
http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2000JanMar/att-0250/01-
transforms2.htm

It would probably be useful to show the example in 6.6.3.4 in the context
of the transform and Xpath element.

<john>True.</john>

>SignatureValue and KeyInfo child elements and the and the DigestValu

(typo)

In the SignatureValue example I might be confused (these small screens at
the IETF make it hard for me to think <smile>) but why eliminate
DigestValue? That element type is reserved for the reference digests,
which do not change during actual signature generation. The digest value
of the SignedInfo does change, but that is not explicitly represented so
it need not be eliminated. Also, eliminating KeyInfo (and any
objects) seems odd. This is at the signers option, but if I were signing
the Signature, I'd want to sign that info as well.

<john>
The expression is written to filter the data that will be digested by
DigestValue (as evidenced by the fact that it omits DigestValue). The
KeyInfo 'can be' assigned before computing DigestValue.  However, I cannot
recall anywhere in the spec  that says that implementations must assign
KeyInfo before computing DigestValue.  Perhaps I missed it (please point it
out as I would be happier if it were there), and if it isn't there, then
perhaps it should be.  Once it is, then you are right that KeyInfo need not
be omitted.

I omitted KeyInfo because of the possibility that DigestValue could be
computed beforehand.  By leaving it out, my example works regardless of how
the spec is written.  Note that it does no harm to leave out the KeyInfo
since it will be signed by the SignatureValue (right?), and there is no
mechanism for omitting material from that which SignatureValue signs.
</john>

Also, would it be
better to set the context node to the the closest ancestor Signature
element (instead of at the document root)?

<john>
Actually, no.  An enveloped signature is a signature is enveloped by some
larger document that we would like to sign.  The desired root of the
document was indicated to us and should not be changed by us since we would
be leaving out information that the user wants to sign.

Furthermore, in general there is no condition under which the transform
should change the context node to be other than how it is specified now.
The transform is assumed to have no special knowledge about the input, nor
its place within that input.  The transform only knows that it has received
some input from a previous transform and that it must apply the expression
to that data.

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

</john>

Received on Monday, 27 March 2000 14:42:34 UTC