RE: Updated c14n Spec

Hi David,

-----Original Message-----
From: w3c-ietf-xmldsig-request@w3.org
[mailto:w3c-ietf-xmldsig-request@w3.org]On Behalf Of David Blondeau
Sent: Monday, June 19, 2000 11:57 AM
To: John Boyer; Petteri Stenius; w3c-ietf-xmldsig@w3.org
Cc: XML DSig
Subject: Re: Updated c14n Spec


Hi John and Petteri,

I just thought to something that annoy me and maybe it was what Petteri was
thinking about.
With the new c14n draft, the canonicalization of the SignedInfo element is
highly context dependant, that is, when generating a signature, you need to
know where the Signature element will be in the final document before doing
the canonicalization because you need to have the namespaces in scope for
the SignedInfo element.

<john>
The most important thing to realize is that the Signature element is
typically placed in the document before any kind of canonicalization occurs.
Before the creation of the signature, the Signature element stands as a
specification for the signature to be created.
</john>

This problem is especially visible for enveloped
signatures.

<john>
I do not understand why this problem is more prevalent for enveloped
signatures.  The term 'enveloped' refers to a property of calculating a
DigestValue, whereas the canonicalization of SignedInfo is necessary for the
calculation of a SignatureValue.  All signatures undergo SignatureValue
calculation.
</john>

So you need to put the Signature in the document before doing any
canonicalization.

I agree with the need of context when doing subset canonicalization but IMO,
this is really a problem in the context of Signature generation. With that,
a signature cannot be moved without a lot of precaution and creation of
composite document can be tricky.

This was not the case with the 20000119 draft since an element declared only
those namespaces that
appear on the element itself and on the element's attributes and then the
SignedInfo element was canonicalized the same way wherever the Signature
element was in the document..

<john>
Actually, the 20000119 c14n draft has a similar problem in addition to the
prior problems we discussed.  SignedInfo is a special case that we have
grouped into the larger category of what we should be doing when signing an
element from a document, e.g. what do we sign when an element has been
indicated by URI="#E"?  If we cut an element E and then paste it someplace
else that has a different namespace context, should the signature break?

In general, the answer is that the signature should break because the change
of context may change the interpretation of E.  Returning to the SignedInfo
example, if the dsig namespace is declared as the default for the Signature
element, we would expect that default to propagate down to the SignedInfo.
If someone changes the dsig namespace URI to point to a newer version of the
spec, then the hash on the SignedInfo should break because the signature on
SignedInfo is governed by the rules set forth in a spec other than the one
indicated by the newer URI.

Note that this is in addition to the problem that it is not realistically
possible to assess whether an element E is using a namespace declaration.
Again, in the case of SignedInfo, it is certainly possible to generate an
XPath transform such that the omission of namespace context from SignedInfo
would ultimately allow changes to the referenced resource that were not
intended by the XPath transform author.  Specifically, if the transform
tries to omit data based on evaluating a certain expression, then changing
the namespace declarations can allow additions to the referenced resource
that are omitted (and hence do not break the signature despite the intent of
the XPath transform author).

Thus, we do not achieve full security unless the namespace declarations used
to evaluate transforms and compute DigestValue results is identical to the
namespace context used when generating the signature, which means that we
have to sign the full namespace context of SignedInfo.

In conclusion, it seems that most applications are not going to have a
problem with this, and the ones that must move signatures out of the
originating document must indeed use more care in pasting the signatures
into the same context.  Still, this has to be one of the best points of
interest raised during this process!

***************************************
John Boyer,
Software Development Manager

PureEdge Solutions (formerly UWI.Com)
Creating Binding E-Commerce

v:250-479-8334, ext. 143 f:250-479-3772
1-888-517-2675  http://www.PureEdge.com
***************************************

</john>

David

Received on Monday, 19 June 2000 20:25:21 UTC