[xmlsec] Using XMLSec with other crypto engines

[Tejkumar Arora]

Thanks for this. It will make the support of other crypto libs easier.

Besides moving code around to separate out openssl, there are
a couple other issues.

1. Crypto initialization : XMLSEC library needs to allow for Crypto
Initialization to happen in the Application OR the library (not BOTH).
The reason is that, atleast for NSS, the initialization is not
idempotent. The application may have already done the initialization
in a different part of the code. Example scenario: a server starts
up, does the NSS init, serves some requests; and down the line needs
to load the xmlsec library for a certain request... xmlsec cannot
initialize NSS again. You can do this by adding a hint flag to the
xmlSecInit function (preferable), or adding a separate hint function
(if you want to maintain src compatibility)

2. The notion of reading certs/keys from files is embedded fairly
deeply (API functions, xmlsec command). This works very well for
openssl. With NSS, certs are in a certdb, and keys in a keydb, and
are normally accessed from the db. I don't know about other crypto
libs. One can export a cert/pvtkey from the NSS db into a pkcs12
file and then read from it, but that is just a workaround and
not the normal mode of operation with NSS. Expecting NSS
users to export certs/keys out of their db just so they can use
XMLSEC is unreasonable. I beleive you need to support the alternative
source for certs/keys in the xmlsec cmd line, and in your API.
Comments anyone?.

Also, do you have any plans to enhance the config tool?.
(for example, something like
   --crypto=<openssl | NSS | .... > --with-crypto=/bla/path.. ).


regards,
-Tej

Aleksey Sanin wrote:

> Hi, All!
>
> In the last few weeks I was asked by a number of people about
> using XMLSec library with other (non OpenSSL) crypto engines
> (NSS, MS CryptoAPI, etc.). I kept this feature in mind from
> the beginning and it looks like it is a right time to do this. Shortly
> the plan is to move all the OpenSSL depended code into separate
> folders (i.e. include/xmlsec/openssl and src/openssl). I don't expect
> any major changes in the code (may be moving some functions around).
>
> If you do not use any OpenSSL specific features of XMLSec (like,
> xmlSecX509Data structure definition from xmsec/x509.h file) then
> you should expect no changes in your code at all. Otherwise, you will
> need to add some additional includes (for example, in the case above,
> you'll need to add "#include <xmlsec/openssl/x509.h>"). The good
> news is that all the changes could be spotted during compilation time :)
> BTW, OpenSSL will still be a default crypto engine.
>
> I am going to make this change in the next couple weeks. Most likely,
> CVS builds be broken at some point. Please use the 0.0.10 version
> instead.
>
> If you have any questions, comments or problems because of the
> proposed change then do not hesitate to write a message to the xmlsec
> mailing list, please.
>
> With best regards,
> Aleksey
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.aleksey.com/pipermail/xmlsec/attachments/20021105/65475f66/attachment.htm