Return-Path: 
 <dev-return-7915-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 82C509EF4
	for <apmail-santuario-dev-archive@www.apache.org>;
 Wed, 28 Mar 2012 15:10:03 +0000 (UTC)
Received: (qmail 95493 invoked by uid 500); 28 Mar 2012 15:10:03 -0000
Delivered-To: apmail-santuario-dev-archive@santuario.apache.org
Received: (qmail 95474 invoked by uid 500); 28 Mar 2012 15:10:03 -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 95463 invoked by uid 99); 28 Mar 2012 15:10:03 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 28 Mar 2012 15:10:03 +0000
X-ASF-Spam-Status: No, hits=-0.0 required=5.0
	tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of Clement_Pellerin@ibi.com
 designates 64.74.32.43 as permitted sender)
Received: from [64.74.32.43] (HELO ibigatef.ibi.com) (64.74.32.43)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 28 Mar 2012 15:09:56 +0000
Received: from ibixmailf.ibi.com (127.0.0.1) id hecks80171s8 for
 <dev@santuario.apache.org>;
 Wed, 28 Mar 2012 11:09:36 -0400 (envelope-from <Clement_Pellerin@ibi.com>)
Received: from IBIEXCHF.ibi.com ([172.30.176.86])
	by ibixmailf.ibi.com (SonicWALL 7.3.4.5721)
	with ESMTP; Wed, 28 Mar 2012 11:09:36 -0400
Received: from IBIUSMBSB.ibi.com ([172.30.176.80]) by IBIEXCHF.ibi.com
 ([172.30.176.86]) with mapi; Wed, 28 Mar 2012 11:17:53 -0400
From: "Pellerin, Clement" <Clement_Pellerin@ibi.com>
To: "dev@santuario.apache.org" <dev@santuario.apache.org>
Date: Wed, 28 Mar 2012 11:09:43 -0400
Subject: RE: Extra xmlns after decrypt
Thread-Topic: Extra xmlns after decrypt
Thread-Index: Ac0MxwVpwRWvS6qERk68s7Zq9ti2WAAINx3w
Message-ID: <9892EC6224DBC54598164D1F77721D751E48D4EF40@IBIUSMBSB.ibi.com>
References: <9892EC6224DBC54598164D1F77721D751E48B7FF59@IBIUSMBSB.ibi.com>
 <CAB8XdGDdYL1Fy-UcAazGe2CMZKLOZ4YXtWDq7jJGet08qa3muA@mail.gmail.com>
In-Reply-To: 
 <CAB8XdGDdYL1Fy-UcAazGe2CMZKLOZ4YXtWDq7jJGet08qa3muA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mlf-Version: 7.3.4.5721
X-Mlf-UniqueId: o201203281509350273925
X-Virus-Checked: Checked by ClamAV on apache.org

There are two issues here.

1- Decrypting does not produce the same Element as the one that was encrypt=
ed.
2- Encrypting multiple elements does not produce the same result for identi=
cal subtrees.

Issue 1 is a direct result of choosing a standard canonicalization algorith=
m.
Inclusive C14N adds namespace declarations inherited from the context.
You can configure XMLCipher to use Exclusive C14N but that leaves out
namespace declarations that are not explicitly used.
I believe to solve issue 1 we need to implement a non-standard canonicaliza=
tion
that simply emits the nodes as is.

Issue 2 is because the canonicalizer has a flag causing it to behave differ=
ently
the first time it is used. I have logged SANTUARIO-308 for this.


-----Original Message-----
From: Colm O hEigeartaigh
Sent: Wednesday, March 28, 2012 5:42 AM

It's probably a (minor) bug in the canonicalization code.

On Thu, Mar 22, 2012 at 7:26 PM, Pellerin, Clement wrote:
> I start with this document:
>
> <env:Envelope
> xmlns:env=3D"http://schemas.xmlsoap.org/soap/envelope/"><env:Body><elem>
> aa</elem></env:Body></env:Envelope>
>
>
>
> I encrypt the <elem> element and immediately decrypt it. The resulting=20
> document has an extra namespace declaration:
>
> <env:Envelope
> xmlns:env=3D"http://schemas.xmlsoap.org/soap/envelope/"><env:Body><elem
> xmlns:env=3D"http://schemas.xmlsoap.org/soap/envelope/">aa</elem></env:B
> ody></env:Envelope>
>
>
>
> The funny thing is, if I encrypt two sibling <elem> elements, only the=20
> first one has the extra namespace declaration.