[xmlsec] xmlsec-nss patch
aleksey at aleksey.com
Mon Jul 21 09:52:49 PDT 2003
>Another reason I went with the approach I took is that
>it is more flexible (for example, it allows you to
>pre-populate the db with anything you wanted...).
>It gives any crypto implementation a chance to run
>some start/stop scripts.
Well, I don't see problems with start/stop script. Again, the logic is:
if config is not NULL and NSS DB exist: open it
if config is not NULL and there is no NSS DB: create it
if config is NULL: init NSS w/o DB
If anyone already has an NSS DB then there is no problem at all.
>The generic keysstore interface defines the keystorefindmethod
>to return a "xmlsecKeyPtr". In other words, the method is
>returning xmlsec objects and not just crypto objects.
>The xmlsec object contain a lot more info than
>just the crypto handles. So NSS db can't replace the
>keystore completely. I'm using the NSS db as an
>alternative source of keys (sort of a "read-through" cache).
>I was thinking about speeding up lookups in the simple
>keysstore, but it is not easy to replace the list with
>a hashtable because many different criteria are used
>to lookup a key, and may not all be defined (name, type,
Probably you can't eliminate the list based store until you have
from NSS DB. After that there should be no problem. You just re-create
object from NSS DB key handle every time you need it.
More information about the xmlsec