Return-Path: 
 <dev-return-8299-apmail-santuario-dev-archive=santuario.apache.org@santuario.apache.org>
X-Original-To: apmail-santuario-dev-archive@www.apache.org
Delivered-To: apmail-santuario-dev-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 200D5110BB
	for <apmail-santuario-dev-archive@www.apache.org>;
 Fri, 22 Aug 2014 11:38:31 +0000 (UTC)
Received: (qmail 96393 invoked by uid 500); 22 Aug 2014 11:38:30 -0000
Delivered-To: apmail-santuario-dev-archive@santuario.apache.org
Received: (qmail 96360 invoked by uid 500); 22 Aug 2014 11:38:30 -0000
Mailing-List: contact dev-help@santuario.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@santuario.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@santuario.apache.org>
List-Post: <mailto:dev@santuario.apache.org>
List-Id: <dev.santuario.apache.org>
Reply-To: dev@santuario.apache.org
Delivered-To: mailing list dev@santuario.apache.org
Received: (qmail 96346 invoked by uid 99); 22 Aug 2014 11:38:30 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 22 Aug 2014 11:38:30 +0000
X-ASF-Spam-Status: No, hits=-0.0 required=5.0
	tests=RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of lkrapf@adobe.com designates
 207.46.163.140 as permitted sender)
Received: from [207.46.163.140] (HELO
 na01-bn1-obe.outbound.protection.outlook.com) (207.46.163.140)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 22 Aug 2014 11:38:24 +0000
Received: from [10.132.1.253] (192.147.117.11) by
 BL2PR02MB322.namprd02.prod.outlook.com (10.141.91.15) with Microsoft SMTP
 Server (TLS) id 15.0.1015.17; Fri, 22 Aug 2014 11:38:00 +0000
Message-ID: <53F72B9D.9030508@adobe.com>
Date: Fri, 22 Aug 2014 13:38:05 +0200
From: Lars Krapf <lkrapf@adobe.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: <dev@santuario.apache.org>
Subject: XMLCipher digest / serialization problem
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [192.147.117.11]
X-ClientProxiedBy: DB4PR03CA0024.eurprd03.prod.outlook.com (25.160.39.162) To
 BL2PR02MB322.namprd02.prod.outlook.com (10.141.91.15)
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;UriScan:;
X-Forefront-PRVS: 0311124FA9
X-Forefront-Antispam-Report: 
	SFV:NSPM;SFS:(6049001)(6009001)(18543002)(199003)(189002)(21056001)(83506001)(80022001)(83072002)(85852003)(36756003)(106356001)(229853001)(92566001)(86362001)(64706001)(81342001)(15975445006)(99396002)(92726001)(50466002)(90102001)(80316001)(105586002)(19580395003)(87976001)(65956001)(87266999)(81542001)(66066001)(47776003)(20776003)(59896002)(83322001)(2351001)(107886001)(74502001)(42186005)(15202345003)(77096002)(74662001)(31966008)(79102001)(50986999)(107046002)(76482001)(102836001)(85306004)(33656002)(65816999)(54356999)(46102001)(110136001)(95666004)(23756003)(77982001)(101416001)(64126003)(4396001);DIR:OUT;SFP:;SCL:1;SRVR:BL2PR02MB322;H:[10.132.1.253];FPR:;MLV:sfv;PTR:InfoNoRecords;A:1;MX:1;LANG:en;
X-OriginatorOrg: adobe.com
X-Virus-Checked: Checked by ClamAV on apache.org

Hello xmlsec

I have a weird problem with XML decryption of a SAML assertion (digest
mismatch), and have really hit a wall here. Maybe you have a hint for
me. This worked fine in xmlsec 1.4.4 but after upgrading to 2.0.1 (Java,
in an OSGi environment) signature verification fails because of a digest
mismatch.

Here is what happens, as far as I understand it (please correct me if
I'm missing something):

1) I call XMLCipher.doFinal() on an EncryptedAssertion element
2) The contents are first decrypted to a byte-array, which is then
passed to AbstractSerializer.createContext() which wraps a <dummy>
element around it, traverses the elements up to the root node and adds
all parent namespaces to it.

So now we have something like this (the xmlns attributes in <dummy> come
from the parent samlp:Response element):

<dummy xmlns:samlp="urn:oasis.."
xmlns:saml="urn:oasis.."><saml:Assertion xmlns:samlp="urn:oasis.."
xmlns:saml="urn:oasis.." ID="..." IssueInstant="..."
Version="2.0">...</saml:Assertion></dummy>

3) This is then passed to deserialization to create the DOM representation.

Now, what happens in the deserialization is that the inner namespace
declarations get added as AttrImpl objects instead of AttrNSImpl (this
only happens to the two xmlns attributes, I suspect because they are
already defined in the dummy element?) - the other attributes from the
saml:Assertion element get added correctly as AttrNSImpl objects.
(the document is namespace aware).

Now, before digest computation c14n is called on this object.
(I'm using http://www.w3.org/2001/10/xml-exc-c14n#) -
However Canonicalizer20010315Excl now stumbles over the two attributes
from above, and does _not_ recognize them as namespace declarations,
because in handleAttributesSubtree() (Line 187)
attribute.getNamespaceURI() will obviously return null on these two
attributes, with the result that the NS attributes will get added twice,
leading to broken XML and a wrong digest computation.

This is what the contents look like before digest computation (note the
redundant xmlns:saml attribute):

<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="..." IssueInstant="..." Version="2.0"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">

If I debug into it, and suppress adding the NS attributes to the dummy
element in the AbstractSerializer, then everything works perfectly.

I suspect a bug in the XML parser/deserialization, but I'm really lost
here. Does anyone have a hint on where to look next? Or is this a known
issue?

Thanks and best greetings
Lars