Encryption design - I need some input

[Berin Lautenbach <be...@ozemail.com.au>]

Peoples,

Am having some fun with integrating encryption into the library, and 
need some thoughts.

As I understand the main signature library, it builds the DOM tree at 
the same time as the various objects are created.  I.e. if I do a "new 
KeyInfo()", then I get back something with a tree already created.  If I 
then add a KeyName() object, a new <KeyName/> element gets immediately 
added as a child to the KeyInfo DOM Node.

XMLCipher, however, uses the marshaller approach.  I build everything up 
and then call "toElement()" which turns everything to a DOM tree at that 
point.  Any subsequent changes are not immediately reflected in the 
associated DOM tree.

Now I'm adding KeyInfo support to XMLCipher.  The easiest thing to do 
(which I'm doing) is to add EncryptedKey to 
org.apache.xml.security.keys.KeyInfo and then use this version of 
KeyInfo inside XMLCipher.

Gets messy when you recreate DOM trees (marshall the XML) more than once 
- the KeyInfo returns the same DOM Nodes as before, but everything else 
is re-created.

What are peoples thoughts?  Is it best to :

1.  Leave my tactical solution in place and just accept that the two 
will always work differently.  I don't like this - I believe the library 
should be consistent.
2.  Move the Signature code to use a marshaller (_not_ trivial, and 
significantly complicates actual signing.  *But* it fits in more 
naturally with the JSR105.)
3.  Move the encryption code to a "build the DOM as I build the objects" 
approach.  I favour the latter, but then it's the way I've done the C 
code, so I find it more natural.

Thoughts?

Cheers,
	Berin

Re: Encryption design - I need some input

[Axl Mattheus <ax...@sun.com>]

All,

I'm back from leave! Nice (NOT)!

OK. Here are my thoughts... When I designed the XML Enc code, I had 
input from Sean Mullan and Erwin van der Koogh (who were/are active in 
the JSR104/105/106 space). I also looked at various experimental and 
comercial implementations of XML encryption libraries in C,C++, Ada and 
Java. As a result of the input I got from Sean et al, I designed the XML 
Enc API with three objectives in mind.

   1. XML Enc API should fit in with the (upcoming) JSR106 (XML Enc)
      straw man API.
   2. XML Enc should resemble and be compatible with the JSR105 (XML
      Sig) API.
   3. The XML Enc implemenation should make life easy for the developers
      who are familiar with the javax.crypto.Cipher class.

As a result I came up with a design that looks like javax.crypto.Cipher 
that will (hopefully) also be the underlying implementation for the 
JSR106 API when it comes along.

I understand and appreciate your concerns about the "compatibility" and 
"consistency" of the Sig and Enc code. I planned to expose 
XMLCipher.Serializer and XMLCipher.Factory to make it easier to build 
the appropriate XML (DOM) for the XML Enc implementation. If we do that, 
AND we do the same for the Sig implementation, we will have the best of 
both worlds - consistent APIs that will fit in kind of "naturally" 
underneath the JSR105/106 implementations.

Fire away with your thoughts...

Ax/

Berin Lautenbach wrote:

> Peoples,
>
> Am having some fun with integrating encryption into the library, and 
> need some thoughts.
>
> As I understand the main signature library, it builds the DOM tree at 
> the same time as the various objects are created.  I.e. if I do a "new 
> KeyInfo()", then I get back something with a tree already created.  If 
> I then add a KeyName() object, a new <KeyName/> element gets 
> immediately added as a child to the KeyInfo DOM Node.
>
> XMLCipher, however, uses the marshaller approach.  I build everything 
> up and then call "toElement()" which turns everything to a DOM tree at 
> that point.  Any subsequent changes are not immediately reflected in 
> the associated DOM tree.
>
> Now I'm adding KeyInfo support to XMLCipher.  The easiest thing to do 
> (which I'm doing) is to add EncryptedKey to 
> org.apache.xml.security.keys.KeyInfo and then use this version of 
> KeyInfo inside XMLCipher.
>
> Gets messy when you recreate DOM trees (marshall the XML) more than 
> once - the KeyInfo returns the same DOM Nodes as before, but 
> everything else is re-created.
>
> What are peoples thoughts?  Is it best to :
>
> 1.  Leave my tactical solution in place and just accept that the two 
> will always work differently.  I don't like this - I believe the 
> library should be consistent.
> 2.  Move the Signature code to use a marshaller (_not_ trivial, and 
> significantly complicates actual signing.  *But* it fits in more 
> naturally with the JSR105.)
> 3.  Move the encryption code to a "build the DOM as I build the 
> objects" approach.  I favour the latter, but then it's the way I've 
> done the C code, so I find it more natural.
>
> Thoughts?
>
> Cheers,
>     Berin
>
>