[xmlsec] Using XMLSec with other crypto engines
Tejkumar Arora
tej@netscape.com
Tue, 05 Nov 2002 19:14:20 -0800
--------------030702060309020105000706
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
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
>
--------------030702060309020105000706
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!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>
--------------030702060309020105000706--