[xmlsec] Using XMLSec with other crypto engines

[Aleksey Sanin]

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


You are welcome.

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

Completelly agree. Moreover, I did this 10 minutes ago :)
There will be two initialization callbacks :
    xmlSecCryptoInit --- called internally from xmlSecInit
    xmlSecAppCryptoInit --- called from xmlsec application
The same applies to shutdown.

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

All the "file related" functions are in xmlSecSimpleKeysManager.
This is an example and simple implementation of the xmlSecKeysManager
interface. Initially I wrote this with the only goal to use in the 
xmlsec command
line utility. Any real application should probably  implement its own keys
manager.
I don't see a big problem with having these APIs. In NSS case you'll
likely will implement these functions in order to make xmlsec utility
work plus any other NSS specific functions to use in real environment.

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

I prefer --with-openssl=..., --with-nss=...,.... Anyone who wants to add 
a new
crypto engine just adds it to the list. OpenSSL will stay default one 
and will
be used if no other crypto engine is specified.

Aleksey.