Re: namespace question

This is quite a serious problem with the proposed canonicalization
for XMLDSIG purposes.

IOTP, echeck, and I'm sure other applications, assume that you can
move a siganture from one document to another.  (IOTP has a technique
to assure unique IDs while echeck uses relative references to avid ID
conflicts.)

I don't off hand see a solution to this other than to require the
application to assure that all relevant namespace declaration are
imported into the SignedInfo element.

Donald

From:  Kevin Regan <kevinr@valicert.com>
Content-return:  allowed
Date:  Fri, 21 Jul 2000 13:13:40 -0700
To:  John Boyer <jboyer@PureEdge.com>, Kevin Regan <kevinr@valicert.com>,
            "Joseph M. Reagle Jr." <reagle@w3.org>
Cc:  w3c-ietf-xmldsig@w3.org
Message-id:  <27FF4FAEA8CDD211B97E00902745CBE2017C8BBA@seine.valicert.com>

>Yes, having implemented this, it seems to make more sense this
>way.  However, it would make any interface for computing
>nested signatures very complex (luckily for me, I don't have
>the need for such functionality :-) ).
>
>--Kevin
>
>-----Original Message-----
>From: John Boyer [mailto:jboyer@PureEdge.com]
>Sent: Friday, July 21, 2000 1:01 PM
>To: Kevin Regan; Joseph M. Reagle Jr.
>Cc: w3c-ietf-xmldsig@w3.org
>Subject: RE: namespace question
>
>
>Hi Kevin and Joseph,
>
>Yes, a signature will break if you move it into a different namespace
>context, whether or not the changed namespaces are actually being used
>within the Signature element.
>
>Canonicalizing an element E must include the full namespace context
>because
>it is impossible to determine which namespaces are actually being used
>with
>E.  E could be an application-specific element with textual content that
>makes reference to some namespace.  The Signature element is simply an
>instance of this element E.  There can be an XPath Transform somewhere
>within the content of Signature.  As well, SignatureProperties appear to
>be
>fairly open, so namespace references could exist within them that we
>have no
>way of determining.
>
>So, the reason we don't restrict namespace context to the subset of the
>namespace context in use is because we have no real way of specifying
>how to
>determine the desired namespace context subset.
>
>Finally, if we were to omit namespaces that are being used, security
>holes
>result.  For example, suppose I have an XPath transform that keeps all
>nodes
>in a referenced document D except omitting those based on a certain
>namespace qualified tag.  The namespace is available to the XPath
>transform
>but does not get signed.  Therefore, the namespace assignment can be
>changed
>to a different URL without breaking the signature and without breaking
>the
>ability to evaluate the XPath expression.  Thus, I am now able to add
>unintended information to D without breaking the signature.  This
>violates
>the notion of document closure.
>
>John Boyer
>Development Team Leader,
>Distributed Processing and XML
>PureEdge Solutions Inc.
>Creating Binding E-Commerce
>v: 250-479-8334, ext. 143  f: 250-479-3772
>1-888-517-2675   http://www.PureEdge.com <http://www.pureedge.com/>
>
>
>-----Original Message-----
>From: w3c-ietf-xmldsig-request@w3.org
>[mailto:w3c-ietf-xmldsig-request@w3.org]On Behalf Of Kevin Regan
>Sent: Wednesday, July 12, 2000 12:33 PM
>To: Joseph M. Reagle Jr.
>Cc: w3c-ietf-xmldsig@w3.org
>Subject: Re: namespace question
>
>
>
>This brings up a few other issues.  If the namespace declarations of the
>parents of the Signature node are to be included in the
>canonicalization,
>you can not simply create a single signature and place it in multiple
>locations within the final document.  You would have to compute the
>signature multiple times, in a context-sensitive way, even if the two
>signatures signed the same set of references.
>
>Also, we have to look at what this means for Object elements
>being signed.  In this case, the Signature object must be
>created, with its associated namespace declarations and
>the digests of Objects must be computed, taking into account
>the namespace declarations of the Signature element as well
>as its parent elements.
>
>Now, let us apply this to nested signatures (a Signature element
>within an Object element of another Signature element).  In this
>event, how was the nested Signature element created?  Normally,
>it seems to be the case that a nested signature was created by
>simply grabbing that signature from somewhere else (it had already
>been created), and placing that in an Object element of another
>signature.  This would not be possible if signatures are
>context-sensitive.
>
>I'm wondering if it would make sense to terminate the namespace
>declaration search at the Signature and Object element boundaries.
>In this case, we avoid the various problems above.
>
>--Kevin
>
>
>On Wed, 12 Jul 2000, Kevin Regan wrote:
>
>>
>> When signing a portion of an XML document (and Element and its
>> children), it is necessary to have the entire document in order
>> to determine the namespace declarations of the parents of the
>> Element.
>>
>> An XML Signature represents only a portion of a document.
>> Once the Signature element and its children are created,
>> it will be inserted somewhere in an XML document.
>> Therefore, it may not be known in advance what the parent
>> Element of the Signature element will be.
>>
>> My question is, when canonicalizing the Signature element
>> to compute the SignatureValue, is it necessary to include
>> the namespace declarations of the parents of the Signature
>> element.  If so, it is necessary to know where in the enclosing
>> XML document that the newly generated signature will be inserted.
>>
>> --Kevin
>>
>>
>> > This is done such that you can move a signature and ensure its
>> namespace
>> > context is taken with it.
>> >
>> >  >  What I'm not exactly clear on
>> >  >is if this applies to the actual Signature element for the
>signature
>> > being
>> >  >created.
>> >
>> > I don't quite follow...
>> >
>> >  >I don't think that it does (I don't believe that you need to
>> >  >look at the parent elements of the Signature element to determine
>> > their
>> >  >namespace declarations)?  Is this correct?  If not, wouldn't it
>mean
>> > that
>> >  >the insertion point for the Signature element must be known in
>> advance
>> > so
>> >  >that these declarations can be obtained?  Are there any
>differences
>> > for
>> >  >detached, enveloped, or enveloping signatures?
>> >
>> > What do you mean known in advance?
>> >
>> >
>> > _________________________________________________________
>> > Joseph Reagle Jr.
>> > W3C Policy Analyst                mailto:reagle@w3.org
>> > IETF/W3C XML-Signature Co-Chair   http://www.w3.org/People/Reagle/

Received on Monday, 24 July 2000 11:09:02 UTC