[xmlsec] xmlsec-nss patches from Sun( 2003-07-22 )
Andrew.Fan at sun.com
Wed Jul 23 20:29:01 PDT 2003
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
> 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.
>> 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
>> 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
> 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.
More information about the xmlsec