<!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>
Using NSS keys database instead of plain list based simple <br>
keys store is an abslutely right idea. Originaly, the functions<br>
were named "xmlSecAppCreateSimpleKeysManager" but later<br>
I replaced "Simple" with "Default" to reflect the fact that crypto<br>
library can use its own keys storage.<br>
<br>
I think that keys/keys data/keys manager structure already has<br>
clear interfaces. Keys are used in transforms, to get key material<br>
from <dsig:KeyInfo/> we sometime use keys store (this usage does<br>
not have specific interface because I found it very crypto specific).<br>
At the end, keys manager is just a container for keys store objects.<br>
<br>
"key : don't explicitly maintain the X509Data." <br>
<br>
I am not sure I clear understand this. Key is not stored in X509Data.<br>
X509Data only has certificates information. The key is extracted from <br>
X509Data and stored in RSA/DSA key data objects. I think that for NSS<br>
the right approach would be to store in RSA/DSA key data objects <br>
a handle to key in the keys db. The transition from certificates to a
key<br>
should be done in the same way it is usualy done in NSS.<br>
Probably this means that there should be two "types" of RSA/DSA keys:<br>
one that points to a "native" key from keydb and another one that points<br>
to a key from cert. Also please not that you might have a certificate
in <br>
the XML DSig document that does not known in the keysdb.<br>
<br>
<br>
symbols.h : well, I don't like the defines approach myself. However,<br>
I don't feel that creating a large struct with function pointers gives
me any <br>
advantage here. You just have a new big static structure that does not <br>
belong to any real object. IMHO, the only difference between defines
and <br>
such structure is that in defines case we do linking on compilation
step <br>
when in structure case we are linking at runtime. I don't see benefits
at all.<br>
<br>
And actualy, real application would probably use *OpenSSL* or *NSS* <br>
functions anyway. All these xmlSecApp* functions were created to support<br>
my little xmlsec command line utility :)<br>
<br>
<br>
Aleksey<br>
<br>
<br>
<br>
<br>
<br>
<br>
</body>
</html>