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

[Tej Arora]

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