Re: [issue - XMLDSIG] Digital Signature update with IBM XML DSIGSigningclass

[christopher ferris <chris.ferris@east.sun.com>]

Sid/All,

Please see my comments below.

Cheers,

Chris

"Askary, Sid" wrote:
> 
> Posting on behalf of Ralph.
> 
> -----Original Message-----
<snip/>
> 
> (1)  Digest values.  We have run the same baseline document through the
> signing tool twice.  One time the document contains the XPATH transform
> within the Signature element as defined in the specification.  This
> transform should prompt the class to ignore the Signature ,
> TraceHeaderList , and Via elements and all their descendants.  The same
> document was presented to the signing class a second time, this version
> deleted the XPATH statement forcing the digest domain over the entire
> document.  Two different digest values should have been returned--both
> cases returned the same digest value.  I have passed copies of the data
> onto Chris Ferris at Sun.  He is testing the document using his code.  I
> expect similar results.

I believe that this issue was related to the incorrect Algorithm URI specified
with the use of the XPath transform. There may still be an issue with the
verification of the signature, but the digesting problem seems to have been
resolved. I'm still working on verifying this for myself.

> 
> (2) Namespace.  The specification requires that the signature elements
> be qualified within a namespace designated as 'ds:'.   This caused
> improperly identified tags to be generated by the signing tool when a
> signature is generated for a template file.  The tool performed its
> tasks and inserted <KeyInfo> and its children, but identified them as
> residing with the default namespace.  We are treating this as a bug.
> Our solution (aligned with similar findings at Sun) is to declare the
> Signature element within the default namespace rather than the namespace
> identified in the specification.

The TR&P spec does not require any specific namespace qualifier (e.g. ds:).
Any namespace qualifier is valid from the perspective of an XML parser that
understands and handles namespaces correctly.

There does, however, seem to be an issue with XSS4J when used in conjunction
with their "template" feature in that the elements it inserts (DigestValue(s)
and SignedInfo) is not qualified with the namespace qualifier used for the
remainder of the "template".

The workaround for this is to use a default namespace qualifier for the 
Signature element. e.g.

	<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/"
		xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance"
		xsi:schemaLocation="http://schemas.xmlsoap.org/soap/envelope/
http://ebxml.org/project_teams/transport/envelope.xsd">
	    <SOAP:Header>
		<eb:MessageHeader xmlns:eb="http://www.ebxml.org/namespaces/messageHeader"
			xsi:schemaLocation="http://www.ebxml.org/namespaces/messageHeader
http://ebxml.org/project_teams/transport/messageHeaderv0_99.xsd"
			eb:version="1.0" SOAP:mustUnderstand="1">
			...
		</eb:MessageHeader>
		<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
			...
		</Signature>
	    </SOAP:Header>
	    <SOAP:Body>
		<eb:Manifest xmlns:eb="http://www.ebxml.org/namespaces/messageHeader"
			xsi:schemaLocation="http://www.ebxml.org/namespaces/messageHeader
http://ebxml.org/project_teams/transport/messageHeaderv0_99.xsd"
			eb:version="1.0">
			...
		</eb:Manifest>
	    </SOAP:Body>
	</SOAP:Envelope>

I am also actively investigating as to whether this workaround does indeed
do the trick, but it should.

> 
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-poc-request@lists.ebxml.org