[xmlsec] xmlsec-nss patches from Sun( 2003-07-22 )
aleksey at aleksey.com
Wed Jul 23 21:06:28 PDT 2003
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
that application creates key in advance (and selects it for
by key name, etc.) or it needs to adopt key dynamicaly (for example,
from x509 cert, decrypts encrypted session key, etc.). The situation
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())
From now on lets talk only about the second case: using "dynamic" keys
created/loaded while application is processing *current* signature or
> 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
the multithreading case when apps wants to use different slots in
in two threads. The only solution I can suggest for this is that the map
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
two, say, RSA encryptions one after another while processing *one*
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
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
I would not object if your patch will do whatever works best for you
restriction: "by default" (i.e. if application does nothing) the code
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
Hope this would work for you :)
More information about the xmlsec