First of all, I'll describe some ideas and the functions in the patch.
1. I hope end user initialize NSS and xmlSec only once in his application;
2. In order to simplify the interface between high level and xmlSec, crypto related operations( which xmlSec do not care ) should be done on high level;
3. User has the right and ability to set up the crypto environment for every signature/encryption operation instead of a common one.
-PK11SlotInfo* xmlSecNssGetSlot( CK_MECHANISM_TYPE type ) ;
This interface is used by xmlSec functions internally, it is designed to replace "GetBestSlot". It call "GetBestSlot" if no particular slot list given.
-PK11SlotList* xmlSecNssSetSlotList( PK11SlotList* list ) ;
This interface is used by high level applications. Only the slots in the list are available.
-PK11SlotList* xmlSecNssGetSlotList( void ) ;
This interface is used by high level applications if it want to access or maintain the slot list, such as disable an slot, add a new slot and so on.
-void xmlSecNssFreeSlot( void ) ;
This interface is used by high level applications when no routines need to get slot.
Above four function name is somesence obscure. With you recommendation, I prefer to the following ones:
-PK11SlotInfo* xmlSecNssGetSlot( CK_MECHANISM_TYPE type ) ; -PK11SlotList* xmlSecNssSlotInit( PK11SlotList* list ) ; -PK11SlotList* xmlSecNssGetSlotList( void ) ; -void xmlSecNssSlotShutdown( void ) ;
By now, you should have asked several times, "why Pk11SlotList". Some reason are:
1. NSS provides a set of functions to manage PK11SlotList;
2. User can dynamicly adjust PK11SlotList directly instead of call xmlSec functions, and which is safe also because xmlSec only get and reference the slot handler;
3. xmlSec care less just to find the suitable slot from the list.
See inlines, please.
Aleksey Sanin wrote:
As far as I can understand Andrew's concerns, he wants to make sure
that particular crypto operation is performed on particular crypto device.
Since nobody (except NSS developers :) ) knows how PK11_GetBestSlot()
function selects the crypto device (slot) his point is perfectly valid:
Suppose we have slots A and B that both perform RSA encryption. How to ensure that we always do it on slot A and not on slot B?
Again, IMHO this should be done on NSS level. I.e. there should be
an NSS function that would say: if slot A supports RSA encryption then
always do it on slot A. However, it does not look like NSS guys want or can
do it in NSS level (correct me if I am wrong and there is such a function
already :) ). Thus Andrew wants to have this in xmlsec-nss and personaly
I don't have any objections.
How about this: xmlsec-nss would have following functions:
int xmlSecNssBestSlotInit(void) : Initializes whatever is needed.
It is not the best one, it is the suitable one. So I like the name "xmlSecNssSlotInit". :-P
void xmlSecNssBestSlotShutdown(void) : Shuts down whatever is needed.
Agree.
int xmlSecNssBestSlotAdopt(CK_MECHANISM_TYPE alg, PK11SlotInfo* slot) :
Sets "slot" to be used for "alg" (global inside xmlsec).
No. Which result in complex lines because there are so many crypto mechanism, and which also result in a table that must be maintained internally by xmlSec, it is in-flexible. This is another reason why use PK11SlotList.
PK11SlotInfo* xmlSecNssBestSlotGet(CK_MECHANISM_TYPE* alg):
Returns the slot for "alg" by first looking thru the list of slots
set with xmlSecNssBestSlotSet() function and if matching slot
is not found then it simply calls NSS PK11_GetBestSlot() function
and hopes for the best.
Agree.
Finally we replace PK11_GetBestSlot() with xmlSecNssBestSlotGet() everywhere
inside xmlsec-nss.
By default if user does nothing (i.e. user does not call xmlSecNssBestSlotAdopt
function) we have xmlSecNssBestSlotGet() function that simply calls PK11_GetBestSlot()
function with a little overhead to check that something is NULL (or not NULL).
Andrew's patch does more or less the same thing but it operates with PK11SlotList
which seems less intuitive to me (I might be wrong). As I wrote, functions descriptions
(API docs) would help. Any approach is good for me. In the outlined above API
I would use subclass of xmlSecList to store the slots and algorithms. The only
problem I have is that xmlSecNssBestSlotGet() would need to "duplicate" the returned
slot because code always frees returned slot with PK11_FreeSlot(). I am sure it is possible, \
I just dn't know how to do this. PK11SlotList might do it as well, I just don't know enough
about it.
To Andrew: I missed this when I looked at your patch first time but you have to rename
you functions from xmlSec* to xmlSecNss* (the functions are NSS specific).
I forgot this, so sorry.
Also having
an init function (even if it does nothing) is a good idea: you may visually check your
xmlSecNssInit/xmlSecNssShutdown functions to make sure all inits and shutdowns
are done in correct order. Also probably it's worth it to have a fallback to PK11_GetBestSlot()
in the xmlSecNssGetSlot() function even if there is PK11SlotList initialized.
I don't think so( fallback to PK11_getBestSlot(): I understand this is "if no slot in the slot list meet the require( mechanism ), call this function", right?). If a PK11Slot list specified, it means only those slot in the list are available, while "GetBestSlot" will search all active slots; if not slot list initialized, it means user do not care which slot selected, we can call "GetBestSlot".
xmlsec has other ways to control which algorithms are allowed.
I think xmlSec controls that which algorithms are supported in gerneral. The above functions controls that in a certain session, which crypto devices are permitted.
Thanks, Andrew
Aleksey
_______________________________________________ xmlsec mailing list [EMAIL PROTECTED] http://www.aleksey.com/mailman/listinfo/xmlsec
