Return-Path: 
 <security-dev-return-5291-apmail-xml-security-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-security-dev-archive@www.apache.org
Received: (qmail 28788 invoked from network); 12 Jul 2006 14:06:09 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur.apache.org with SMTP; 12 Jul 2006 14:06:09 -0000
Received: (qmail 15666 invoked by uid 500); 12 Jul 2006 14:06:07 -0000
Delivered-To: apmail-xml-security-dev-archive@xml.apache.org
Received: (qmail 15642 invoked by uid 500); 12 Jul 2006 14:06:07 -0000
Mailing-List: contact security-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
List-Post: <mailto:security-dev@xml.apache.org>
List-Help: <mailto:security-dev-help@xml.apache.org>
List-Unsubscribe: <mailto:security-dev-unsubscribe@xml.apache.org>
Reply-To: security-dev@xml.apache.org
List-Id: <security-dev.xml.apache.org>
Delivered-To: mailing list security-dev@xml.apache.org
Received: (qmail 15631 invoked by uid 99); 12 Jul 2006 14:06:07 -0000
Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 12 Jul 2006 07:06:07 -0700
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
	tests=SPF_HELO_PASS,SPF_PASS,UNPARSEABLE_RELAY
X-Spam-Check-By: apache.org
Received-SPF: pass (asf.osuosl.org: domain of ap-security-dev@m.gmane.org
 designates 80.91.229.2 as permitted sender)
Received: from [80.91.229.2] (HELO ciao.gmane.org) (80.91.229.2)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 12 Jul 2006 07:06:06 -0700
Received: from root by ciao.gmane.org with local (Exim 4.43)
	id 1G0fKp-0006yI-F2
	for security-dev@xml.apache.org; Wed, 12 Jul 2006 16:05:04 +0200
Received: from user8.documentprocessing.com ([user8.documentprocessing.com])
        by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
        id 1AlnuQ-0007hv-00
        for <security-dev@xml.apache.org>; Wed, 12 Jul 2006 16:05:03 +0200
Received: from bob by user8.documentprocessing.com with local (Gmexim 0.1
 (Debian))
        id 1AlnuQ-0007hv-00
        for <security-dev@xml.apache.org>; Wed, 12 Jul 2006 16:05:03 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: security-dev@xml.apache.org
From: Robert Shanahan <bob@directdocs.com>
Subject: subtree c14n canonicalization
Date: Wed, 12 Jul 2006 13:54:15 +0000 (UTC)
Lines: 49
Message-ID: <loom.20060712T003010-136@post.gmane.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@sea.gmane.org
X-Gmane-NNTP-Posting-Host: main.gmane.org
User-Agent: Loom/3.14 (http://gmane.org/)
X-Loom-IP: 65.247.99.8 (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4)
Sender: news <news@sea.gmane.org>
X-Virus-Checked: Checked by ClamAV on apache.org
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N

The following XML is taken from the CanonSubtree sample app, but illustrates an
issue that I've encountered, which is causing a signature verification interop
problem (Keytools and xml-sec).

I've slightly altered the XML from the CanonSubtree sample by adding xmlns="" to
the CanonicalizationMethod element. The second chunk of XML is the result of
Apache xml-sec 1.3 subtree (SignedInfo) canonicalization.

<?xml version="1.0" encoding="UTF-8"?>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
  <SignedInfo>
    <CanonicalizationMethod xmlns=""
Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"></CanonicalizationMethod>
    <SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"></SignatureMethod>
    <Reference URI="http://www.w3.org/TR/xml-stylesheet">
      <DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"></DigestMethod>
      <DigestValue>60NvZvtdTB+7UnlLp/H24p7h4bs=</DigestValue>
    </Reference>
  </SignedInfo>
<Signature>


<SignedInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
    <CanonicalizationMethod
Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"></CanonicalizationMethod>
    <SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"></SignatureMethod>
    <Reference URI="http://www.w3.org/TR/xml-stylesheet">
      <DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"></DigestMethod>
      <DigestValue>60NvZvtdTB+7UnlLp/H24p7h4bs=</DigestValue>
    </Reference>
  </SignedInfo>


Note that xmlns="" has been omitted from the CanonicalizationMethod element.
This is correct in the context of the subtree prior to adding doc level
namespaces to the subtree root (i.e. <SignedInfo> vs <SignedInfo 
xmlns="http://www.w3.org/2000/09/xmldsig#">), but seems incorrect following the
addition of the doc level namespace. I've read the W3C spec several times, yet
it is still not clear to me what the correct behavior is.

And apparently it was not clear to different implementors of the c14n spec,
since Keytools retains xmlns="" in this type of context while xml-sec removes
it, hence xml-sec cannot verify signatures created by Keytools in these contexts.

I'd appreciate any insight or advice.