Use of exclusive c14n when encrypting elements in C++ lib

[Scott Cantor <ca...@osu.edu>]

Berin,

I'm not sure that using exclusive c14n is the best option in the
encryptElement routines for serializing the data to be encrypted. At the
very least, if you're going to do that, you really have to expose an
inclusive prefix capability or there's no way to safely encrypt elements
that contain QName-valued children or attributes, including xsi:type. The
resulting data won't necessarily be well-formed, and break on the other end.

My guess is that signature applications that need excl-c14n are already
using that in the signature, so if you had a signed fragment and then
encrypted it, it would be "safe" to use inclusive c14n when encrypting
because the signature transforms will take care of applying the exclusive
version to the data when verifying the signature later.

As usual, none of this stuff really works right in the general case. We're
all just trying to play enough games to make it appear to work often enough
to fool people. ;-)

-- Scott

Re: Use of exclusive c14n when encrypting elements in C++ lib

[Berin Lautenbach <be...@wingsofhermes.org>]

Scott Cantor wrote:

> If you want to cut a final RC, I can try and do a final round of source and
> RPM builds and make sure it's clean. Red Hat is apparently going to put EL5
> on top of gcc4.1, so I have to make sure things are ok.

RC3 sitting in people.apache.org/~blautenb

Cheers,
	Berin

RE: Use of exclusive c14n when encrypting elements in C++ lib

[Scott Cantor <ca...@osu.edu>]

> > Oh...I know the other thing...have you done any builds against a
> > Xerces 3.0 snapshot?
> 
> Yes - and they broke badly.  I wanted to finalise this version, get it
> out and then do a 1.3.1 with that and a rebuilt configure sctipt (using
> automake).  I.e. API exactly the same as 1.3 but compile under Xerces
> 3.0 and fix the whole unix build process.

Ouch, I didn't expect that. Sounds like a good plan then.

-- Scott

Re: Use of exclusive c14n when encrypting elements in C++ lib

[Berin Lautenbach <be...@wingsofhermes.org>]

Scott Cantor wrote:

> If you want to cut a final RC, I can try and do a final round of source and
> RPM builds and make sure it's clean. Red Hat is apparently going to put EL5
> on top of gcc4.1, so I have to make sure things are ok.

I've built against 4.1 on my deb unstable box.  So theoretically should
be fine.

> 
> Oh...I know the other thing...have you done any builds against a Xerces 3.0
> snapshot?

Yes - and they broke badly.  I wanted to finalise this version, get it
out and then do a 1.3.1 with that and a rebuilt configure sctipt (using
automake).  I.e. API exactly the same as 1.3 but compile under Xerces
3.0 and fix the whole unix build process.

Cheers,	
	Berin

RE: Use of exclusive c14n when encrypting elements in C++ lib

[Scott Cantor <ca...@osu.edu>]

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

Thanks, that's definitely sufficient for now. If you come up with a reason,
please let me know. I haven't been able to come up with any.

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

Yeah, thanks. I've done most of my stuff, and it wasn't too hard, though
some of the memory management is a little convoluted as far as which objects
are owned by what, but I don't have any specific suggestions to make that
are urgent.

If you want to cut a final RC, I can try and do a final round of source and
RPM builds and make sure it's clean. Red Hat is apparently going to put EL5
on top of gcc4.1, so I have to make sure things are ok.

Oh...I know the other thing...have you done any builds against a Xerces 3.0
snapshot?

-- Scott

Re: Use of exclusive c14n when encrypting elements in C++ lib

[Berin Lautenbach <be...@wingsofhermes.org>]

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

RE: Use of exclusive c14n when encrypting elements in C++ lib

[Scott Cantor <ca...@osu.edu>]

> 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

Re: Use of exclusive c14n when encrypting elements in C++ lib

[Berin Lautenbach <be...@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!

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

Cheers,
	Berin

Scott Cantor wrote:

> Berin,
> 
> I'm not sure that using exclusive c14n is the best option in the
> encryptElement routines for serializing the data to be encrypted. At the
> very least, if you're going to do that, you really have to expose an
> inclusive prefix capability or there's no way to safely encrypt elements
> that contain QName-valued children or attributes, including xsi:type. The
> resulting data won't necessarily be well-formed, and break on the other end.
> 
> My guess is that signature applications that need excl-c14n are already
> using that in the signature, so if you had a signed fragment and then
> encrypted it, it would be "safe" to use inclusive c14n when encrypting
> because the signature transforms will take care of applying the exclusive
> version to the data when verifying the signature later.
> 
> As usual, none of this stuff really works right in the general case. We're
> all just trying to play enough games to make it appear to work often enough
> to fool people. ;-)
> 
> -- Scott
> 
> 
>