santuario-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott Cantor" <canto...@osu.edu>
Subject RE: Use of exclusive c14n when encrypting elements in C++ lib
Date Tue, 13 Jun 2006 14:42:26 GMT
> 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


Mime
View raw message