<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
</head>
<body>
<tt>Thanks for this. It will make the support of other crypto libs easier.</tt><br>
<br>
<tt>Besides moving code around to separate out openssl, there are <br>
a couple</tt><tt> other issues.</tt><br>
<br>
<tt>1. Crypto initialization : XMLSEC library needs to allow for Crypto<br>
Initialization to happen in the Application OR the library (not BOTH).<br>
The reason is that, atleast for NSS, the initialization is not<br>
idempotent. The application may have already done the initialization<br>
in a different part of the code. Example scenario: a server starts <br>
up, does the NSS init, serves some requests; and down the line needs <br>
to load the xmlsec library for a certain request... xmlsec cannot<br>
initialize NSS again.</tt><tt> You can do this by adding a hint flag to the<br>
xmlSecInit function (preferable), or adding a separate hint function<br>
(if you want to maintain src compatibility)</tt><br>
<br>
<tt>2. The notion of reading certs/keys from files is embedded fairly<br>
deeply (API functions, xmlsec command). This works very well for<br>
openssl. With NSS, certs are in a certdb, and keys in a keydb, and<br>
are normally accessed from the db. I don't know about other crypto<br>
libs. One can export a cert/pvtkey from the NSS db into a pkcs12 <br>
file and then read from it, but that is just a workaround and <br>
not the normal mode of operation with NSS. Expecting NSS <br>
users to export certs/keys out of their db just so they can use <br>
XMLSEC is unreasonable.</tt><tt> I beleive you need to support the alternative<br>
source for certs/keys in the xmlsec cmd line, and in your API.<br>
Comments anyone?.</tt><br>
<br>
<tt>Also, do you have any plans to enhance the config tool?. <br>
(for example, something like <br>
--crypto=<openssl | NSS | .... > --with-crypto=/bla/path.. ).</tt><br>
<br>
<br>
<tt>regards,<br>
-Tej</tt><br>
<br>
<tt>Aleksey Sanin wrote:</tt><br>
<blockquote type="cite" cite="mid3DC88331.7050702@netscape.com">
<meta http-equiv="Content-Type" content="text/html;">
<title></title>
<!--beginarticle--> <tt>Hi, All!<br>
<br>
In the last few weeks I was asked by a number of people about<br>
using XMLSec library with other (non OpenSSL) crypto engines<br>
(NSS, MS CryptoAPI, etc.). I kept this feature in mind from<br>
the beginning and it looks like it is a right time to do this. Shortly<br>
the plan is to move all the OpenSSL depended code into separate<br>
folders (i.e. include/xmlsec/openssl and src/openssl). I don't expect<br>
any major changes in the code (may be moving some functions around).<br>
<br>
If you do not use any OpenSSL specific features of XMLSec (like,<br>
xmlSecX509Data structure definition from xmsec/x509.h file) then<br>
you should expect no changes in your code at all. Otherwise, you will<br>
need to add some additional includes (for example, in the case above,<br>
you'll need to add "#include <xmlsec/openssl/x509.h>"). The good<br>
news is that all the changes could be spotted during compilation time :)<br>
BTW, OpenSSL will still be a default crypto engine.<br>
<br>
I am going to make this change in the next couple weeks. Most likely,<br>
CVS builds be broken at some point. Please use the 0.0.10 version<br>
instead.<br>
<br>
If you have any questions, comments or problems because of the<br>
proposed change then do not hesitate to write a message to the xmlsec<br>
mailing list, please.<br>
<br>
With best regards,<br>
Aleksey<br>
<br>
</tt></blockquote>
<br>
</body>
</html>