RE: namespace question

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/
> >
>