[xmlsec] xmlsec-nss patch

[Aleksey Sanin]

>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,
>usage, etc..).
>  
>
Probably you can't eliminate the list based store until you have 
symetric keys
from NSS DB. After that there should be no problem. You just re-create 
xmlSecKey
object from NSS DB key handle every time you need it.


Aleksey