santuario-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Lautenbach <be...@wingsofhermes.org>
Subject Re: Use of exclusive c14n when encrypting elements in C++ lib
Date Thu, 06 Jul 2006 09:24:01 GMT
Scott,

I was thinking about this during the day.  I'm going to add a method to
allow the exclusive use to be turned off and that way it can be
deactivated if it makes sense.  I've been wracking my brains to think
about why I used it in the first place, and I know there was a really
good reason but I just can't remember it :<.

On another note - I'm want to get this release done so I can start on
tidying up a few things in the code - which is my personal focus for
1.4.  I know you were having a look at other things in encryption so
just wanted to touch base before I moved it forward.

Cheers,
	Berin

Scott Cantor wrote:

>>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