Mailing-List: contact security-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: security-dev@xml.apache.org
Received-SPF: pass (nike.apache.org: local policy)
From: "Scott Cantor" <cantor.2@osu.edu>
To: <security-dev@xml.apache.org>
References: <BAY105-W15A77C9C60B34878DBBCFA8EE80@phx.gbl>
 <015c01c7d471$13491ca0$39db55e0$%2@osu.edu>
 <200708061054.23113.ralph-xmlsecurity@ralphholz.de>
In-Reply-To: <200708061054.23113.ralph-xmlsecurity@ralphholz.de>
Subject: RE: Signing just one of the elements in a DOMDocument
Date: Mon, 6 Aug 2007 11:10:09 -0400
Organization: The Ohio State University
Message-ID: <003b01c7d83b$e0fd1160$a2f73420$@2@osu.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Thread-index: AcfYB3ASS16XHRdQTuW3x2O97lc4wgANB4ow
Content-language: en-us

> > Yes, but it's somewhat difficult. You can either use an XPath filter
> > transform to select the node, or refer to the node by an ID attribute.
> 
> It's not 100% clear to me how you mean that, but I am new to XML Security
> (though not to XML). Do you see the problem in retrieving the correct XML
> element from the tree (both for signer and receiver), but not in the
> signing process itself?

The signing step is transparent to the caller once you have created the
transforms you want. Other than creating the XPath (quite simple unless you
don't know XPath), it's easy to do.

The problem is in the verification step, where an infinite number of XPaths
produce the same node set, so determining what's been signed is difficult or
inefficient.

ID-based signing is much cleaner, but requires schemas or
application-specific knowledge, at least prior to the emergence of xml:id.

-- Scott