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: [C++] Full XKMS Message Set Implemented
Date: Tue, 14 Mar 2006 14:13:30 -0500
Organization: The Ohio State University
Message-ID: <004e01c6479b$6421af70$099c9280@oit.ohiostate.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
In-reply-to: <44169C3A.5010908@wingsofhermes.org>
Thread-index: AcZHUy2g/yDxh4dFRXiWbbFTqgH5IQAHcd7Q

> Hmm.  Don't have a 64 bit system to do a build on.  Must try and see if
> I can track something down.

I've gotten access to an Opteron, so I can report back. I'll try and get to
it this week. But the Microsoft build by default will report 64 bit issues
as warnings to help identify problems with int sizes and that sort of thing,
so it helps catch things.

> The original idea was that it could re-use objects rather than
> completely deleting and re-allocating all the time.  That was the idea -
> but I haven't yet had time to make it work.

Ok. I'm not sure in practice how valuable it would be, but at a minimum it
seems like that could be handled without actually tracking the objects in a
big list while they're in use.

> The other part was as a message factory - I'm trying to hide the
> implementation from the user.  If you look at the XKMS classes they are
> completely interface only now.  That's where I want the Signature
> classes to be as well.

Understood, my new code has a similar design.

> The message factory side of it could potentially
> be done using static methods, but I wanted to avoid that to keep thread
> handling simpler in complex applications.  (Mind you, if we passed
> ownership straight to the caller then thread issues are pretty much
> non-existant - it's only an issue if we continue to keep a memory of all
> signatures we have allocated.)

Right, I think the factories should be stateless singletons anyway, if
possible.

> Where are you seeing an XSECEnv?  That should be completely hidden
> unless you are manipulating the implementation classes directly!

Well, I am at times because I needed to manipulate ds:KeyInfo information. I
rapidly figured out that this wasn't really fully supported yet, but the
DSIGKeyInfoList stuff uses an XSECEnv internally, so I had to work around
that a little.

I think I'm satisfied for the moment that I need to wrap the KeyInfo stuff
myself. My XML handling classes are more flexible than the stuff in this
library, so while it's a little more work for me up front, it will be better
than relying on, as you say, implementation classes here.

> If you are having to manipulate the Env class directly for normal
> operations then I have a bug somewhere.  For encryption the only things 
> you should need are the Cipher and provider classes.

I haven't touched that stuff yet. I think the problem was that I was pushing
out past the boundaries you had intended and trying to reuse some of the
signature wrapping classes for my own needs.

> Really it just encapsulates all the information that is common for all
> the objects that make up an EncryptedType object.  There is probably a
> nicer way to do it, but I couldn't see it :<.

If it's not supposed to be affecting me, then that tells me where I'm
misusing some of the current classes and where I need to code my own
wrappers.

Thanks,
Scott