[xmlsec] Using XMLSec with other crypto engines

[Tejkumar Arora]

Aleksey Sanin wrote:

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

These functions are used directly or indirectly in xmlsec and also
the example applications. We would definitely want to make xmlsec utility
and the examples work for NSS.

You mention above that these functions will likely be implemented for
NSS. However, these file related functions don't make sense for NSS.
For example: in
xmlSecSimpleKeysMngrLoadPemCert(....., const char * filename....)
there is no "filename" needed for NSS...  ("Pem" in the name is
also not right, but that's a minor point).
The xmlsec utility for the NSS case will not even accept "filenames"
on the command line. In fact, the utility will expect the NSS db location
to be provided... So what we'll need is another flavor of LoadCert above,
(or another flavor of xmlSecSimpleKeysManager altogether? - we should
try to avoid that since most of the keysmngr is re-usable),
and another flavor of the xmlsec utility....

Unfortunately, there's going to have to be some ifdef'ing in the code
to handle crypto differences....

By the way these functions are in keys.h, keysmngr.h, and x509.h, and I 
don't
think are limited to the xmlSecSimpleKeysManager alone.. Here's a list:

xmlSecKeyReadPemCert
xmlSecSimpleKeysMngrLoadPemKey
xmlSecSimpleKeysMngrLoadPemCert
xmlSecSimpleKeysMngrAddCertsDir
xmlSecSimpleKeysMngrAddCertsDir
xmlSecX509DataReadPemCert
xmlSecX509StoreLoadPemCert
xmlSecX509StoreAddCertsDir

Food for thought while you factor out openssl stuff...

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

Agree. This looks better.

>
>
> Aleksey.
>
>
thanks,
-Tej