1. provide a default keys manager which will enable tha suitable slot;
2. read raw key from xml document, assign NULL slot or get slot from the default keys manager;
3. the "getSlot" or "getBestSlot" only appears in xmlSec*Generate functions.
It's possible and pratical, my demo xmlsec-nss crypto do like above except I provide some redundant "getSlot" functions in the implementation of xmlSec*Generate functions.
Discuss and argument is a GREAT way to success.
Aleksey Sanin wrote:
"xmlSecNssKeyDataRsaGenerate" interfaces, I have no such a goog luck. So the 'getSlot' is designed only for "KeyDataXXXGenerate" functions.
The only thing that can use xmlSec*Generate functions is some keys storage (XKMS?)
xmlsec never calls these functions by itself. And if you want, you can have xmlSecNss*GenerateExt()
function with one additional parameter "slot". Then xmlSecNssGenerate() would simply call
xmlSecNss*GenerateExt(..., PK11__GetBEstSlot());
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.
Sure. Again, I think that mapping alg->slot is better than plain "enabled slots list"
(my favorite example again :) ).
So if we provide such a keys manager, "getSlot" only work for key data generator. When we will
use the "KeyDataXXXGenerate" functions?
Never. These functions are used *only* by xmlsec command line utility. And these functions
are not called from xmlsec library itself.
Now, maybe we have agreed where and when "getSlot" works, Only in the "KeyDataXXXGenerate"
interfaces.
See above the suggestion with xmlSecNss*GenerateExt() functions. If you stick with NSS
and don't care about portability (i.e. switching to OpenSSL, etc.) then you can use
xmlSecNss*GenerateExt() instead.
Aleksey
_______________________________________________ xmlsec mailing list [EMAIL PROTECTED] http://www.aleksey.com/mailman/listinfo/xmlsec
