Andrew, Based on the fact that your generalization doesn't require the programmer to do anything extra in the default case, I really have no objections. But I'm still quite unsure that the generalization is needed, and whether there is a good basis for programmers to specify a slot, or that programmers are interested in slot management at all...
BTW, I have no problems understanding your english :) cheers, -Tej Andrew Fan wrote: > It is so hard to make you all understand myself because of my poor > English. :-) My poor English skill! Great, you understand me now. :-) > > 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
