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

[Andrew Fan]

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.