[xmlsec] xmlsec-nss patches from Sun( 2003-07-22 )

[Andrew Fan]

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
>
>
>
>