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

[Aleksey Sanin]

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

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

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.

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

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

Hope this would work for you :)

Aleksey