Mailing-List: contact security-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: security-dev@xml.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
From: "Scott Cantor" <cantor.2@osu.edu>
To: <security-dev@xml.apache.org>
Subject: RE: Use of exclusive c14n when encrypting elements in C++ lib
Date: Tue, 13 Jun 2006 10:42:26 -0400
Organization: The Ohio State University
Message-ID: <001c01c68ef7$972098c0$c4f29280@oit.ohiostate.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-index: AcaOztoXXFwV+MuoTvWcoHnDYYqJWQAKAkQw
In-reply-to: <448E8A45.7060506@wingsofhermes.org>

> The whole thing about serialisation of data prior to encryption is
> fraught with problems.  Exc-c14n fixed some of them for me - but
> obviously there are others I missed!

I know, it's only my intuition that suggests to me that inclusive works
better for this use case, because signatures contain their own tranforms and
c14n directives. So sucking in additional namespaces during encryption
*shouldn't* cause breakage.

> Are you able to give me a fragment of something that breaks? I think I
> can see what you are getting at below, but a concrete example would make
> it easier for me :>.

Here's a simple example that *should* break:

<foo:bar xmlns:foo="..." xmlns:typens="..." xsi:type="typens:extension">
...
</foo

If I encrypt that element, your API will run excl c14n on the DOM to get the
octets. But under exclusive c14n, xmlns:typens is not visibly used, so it
will be stripped.

On the other end when I decrypt it, I'll get back this:

<foo:bar xmlns:foo="..." xsi:type="typens:extension">
...
</foo

If I don't validate, it will parse, because the parser isn't QName aware.
But my code will expect to process xsi:type properly, and won't find typens.

The usual solution of course is the inclusive prefix list, but I think here
your best bet is just use inclusive, so taking out the setExclusive() call
inside the encryption routine should work.

-- Scott