Aleksey Sanin wrote:
From what I am reading, you want to have *context* based list of allowed slots. I am not sure what are you requirements thus I really don't understand what are you trying to achieve. And I don't understand how this list would help ( again, my example with two slots A and B that both can do, say, RSA and DES).
Indeed, in my implementaion, "GetSlot" only when generating a new key( such as: xmlSecNssKeyDataDsaGenerate ) and importing a raw key( such as xmlSecNssKeyDataRsaXmlRead ). I also think there are only the two cases.
AFAIK, the NSS determines the slot for performing particular crypto operation by looking at the key (i.e. key has pointer to slot and if I want to do RSA encryption with *given* key then it would always happen on the same slot).
Yes.
IMHO, we have two different scenarios: 1) Application signs or encrypts something. In this case, application creates (loads, etc.) keys *before* calling xmlsec function. Then xmlsec selects the key and perform crypto operation on the slot specified by the key. I don't see any problem here because application may select any slot for particular key, add the key to keys manager and everything would work fine today.
Yes, for these cases, "getSlot" must not work, because user has assigned the slot with the key.
2) Application decrypts data or verifies signature. In this case it is possible
that application creates key in advance (and selects it for performing operation
by key name, etc.) or it needs to adopt key dynamicaly (for example, extracts
from x509 cert, decrypts encrypted session key, etc.). The situation when
key is created by application in advance is not different from case 1). It would
work as desired with current code.
Agree.
The situation with "dynamicaly loaded key" is
different and this is the case when we use PK11_GetBestSlot()) function today.
From now on lets talk only about the second case: using "dynamic" keys
created/loaded while application is processing *current* signature or encrypted
data.
> 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.
My solution with mapping algorithm-->slot works here. The only thing it misses is
the multithreading case when apps wants to use different slots in different way
in two threads. The only solution I can suggest for this is that the map algorithm-->slot
is changed from global to be xmlSecNssKeysManager specific.
Good suggestion, we have the same options some sense. When I implement the demo, I do not want to introduce the "getSlot" functions, I think that I can get everything from keys manager. When I read a raw key from a xml document, the "xmlSecNssKeyDataRsaXmlRead" interface, for example, has a xmlSecKeyInfoCtxPtr parameter, from where I can get the xmlSecNssKeysManger. But for the "xmlSecNssKeyDataRsaGenerate" interfaces, I have no such a goog luck. So the 'getSlot' is designed only for "KeyDataXXXGenerate" functions.
Can we design that we specify a deault xmlSecNssKeysManager, and every loaded keys ( read from xml document ) bind with the slot that enabled in the manager? That one things I want to do.
So if we provide such a keys manager, "getSlot" only work for key data generator. When we will use the "KeyDataXXXGenerate" functions?
> 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.
I don't think that I want to solve a problem when application wants to perform
two, say, RSA encryptions one after another while processing *one* <enc:EncryptedData/>
node (for example, one RSA session key encrypts data and another RSA key
encrypts RSA session key in key transport). And application wants to do these
two RSA decryptions on *different* slots. IMHO, this is a corner case.
:-(
I think this discussion goes wild :) I don't understand the benefits of using slots list
instead of alg->slot map. But since nobody else besides you wants this feature,
I would not object if your patch will do whatever works best for you with one
restriction: "by default" (i.e. if application does nothing) the code should just
simply call GetBestSlot. Thus your changes would not affect others. Also it would be
great to have this limited to xmlSecKeysManager (i.e. no global static objects/variables).
Now, maybe we have agreed where and when "getSlot" works, Only in the "KeyDataXXXGenerate" interfaces. And I do not stick to my design. Wait a while......! First, I think we need a example: how to initialize the alg->slot map or slot list.
alg-slot:
{
PK11SlotInfo* slot ;
PK11SlotInfo* slot2 ;
if( PK11_DoesMechanism( slot , CKM_RSA_X509 ) ) {
xmlSecNssSlotAdopt( CKM_RSA_X509, slot ) ;
} else if( PK11_DoesMechanism( slot , CKM_RSA_PKCS ) ) {
xmlSecNssSlotAdopt( CKM_RSA_PKCS, slot ) ;
} else if( PK11_DoesMechanism( slot , CKM_RSA_PKCS_KEY_PAIR_GEN ) ) {
xmlSecNssSlotAdopt( CKM_RSA_PKCS_KEY_PAIR_GEN, slot ) ;
} else if( PK11_DoesMechanism( slot , CKM_RSA_9796 ) ) {
xmlSecNssSlotAdopt( CKM_RSA_9796, slot ) ;
} else if( PK11_DoesMechanism( slot , CKM_DSA ) ) {
xmlSecNssSlotAdopt( CKM_DSA, slot ) ;
} else if{
......
}
......xmlSecNssSlotRemove( CKM_RSA_PKCS_KEY_PAIR_GEN, slot ) ; ......
}
slot list:
{
PK11SlotInfo* slot ;
PK11SlotInfo* slot2 ;
PK11SlotList* slist ;
......
slist = xmlSecNssSlotInit( slist ) ;PK11_AddSlotToList( slist, slot ) ; PK11_AddSlotToList( slist, slot2 ) ; ...... PK11_DeleteSlotList( slist, PK11_FindSlotElement( slist, slot2 ) ) ; ...... }
Because all of above two seems work for me, if we can assure only "KeysDataXXXGenerate" depends on the "getSlot", I can accept either.
_______________________________________________ xmlsec mailing list [EMAIL PROTECTED] http://www.aleksey.com/mailman/listinfo/xmlsec
