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

[Andrew Fan]

Aleksey Sanin wrote:

> [......]
>
>> 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.
>
>
> The question I have is: suppose you have to slots A and B that both 
> support
> RSA encryption and DSA signatures. And your application wants to use
> slot A for RSA encryption and slot B for DSA signatures. I understand
> how you can do it with my proposal when application explicitly maps
> algorithm to the slot. I am not sure I understand how you can do it with
> "Pk11SlotList" inteface you suggest: both slots needs to be in the
> list, the GetSlot functions loops thru the list and always selects the 
> first one.
> I see no difference from original GetBestSlot().

A very good question! Tej also mentioned this in another mail. :-( Your 
solution is very good for this case. Think about another cases: Slot A 
and B both support RSA encrytion,  an operation want to transport a RSA 
key ( in A ) with another RSA key( in B ), which is a very common case 
in key management  system. Your solution doesn't work now.

And this case: based on thr first, your application wants to use slot A 
for RSA encryption and slot B for DSA signatures in a wile, in another 
wile slot a for DSA encryption and slot B for RSA signature is required.

Then How can I settle these problems?

For the first case, because user clearly know that he want to perform 
RSA encryption on slot A, so he can set up encryption context with the 
slot list include slot A and disable slot B; the same for signature on 
slot B, setting up signature context include slot B and disbale slot A. 
A more worse case is: he want to perform signature X on slot A, and 
signature Y on slot B. In the case, when performing X, user enable slot 
A and disable slot B in the list. And NSS has provide functions on 
PK11SlotList like these, user is not required to call any xmlSec 
interfaces. I don't think it is too cumbersome, because user clearly 
understand what he want to do and  he must pay for his wish. Indeed, 
this is a reason why I want to provide a more common key manager only 
based on slot list and certificateDB handler.

For the second case. I also have no good ideas. Then think about when we 
will use the "GetBestSlot" function, I recommend only in one case: key 
generator functions. Because if a key is imported from outside, in NSS 
context it should reside in a certain slot. Maybe, a key read from a xml 
document is an exception. But in this case, generally, the key is 
importable, we can select a slot, and bind the key with the slot. So the 
left questions are: when and how a key is generated. If a user generate 
the key, he can import the key into xmlSec routines; if a key is 
generated internally and automatically,  I'am not sure whether the 
conditions of this case also work. If a requirement insist on that 
xmlSec must choice the slot from two smartly, automatically and 
internally create the key, I realy have no any ideas.

Addtional, in reality, most user only care which crypto devices should 
be used, if his crypto devices do not work for some mechanism, he have 
to give up his operation from security consideration. So intuitively, I 
select slot list instead of mechanism.

I think we can continue talk about the interesting topic.

Andrew

>
>
>> It is not the best one, it is the suitable one. So I like the name 
>> "xmlSecNssSlotInit". :-P
>
>
> Sure, I don't care :)
>
>>>    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.
>
>
> See example above.
>
>> 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".
>
>
> Well, it's a difference in our proposals :) In my case, I want to let 
> user only map algorithms
> he cares about and let GetBestSlot() do the rest :) But you are right, 
> in case of "list" type API
> you suggest it's probably not necessary.
>
> Aleksey
>
>
>