Regarding the use of NSS and PKCS#11 crypto modules:

I have talked about this earlier, where I had an NSS *3.1*-enabled app
trying to use a certificate stored on a smartcard for SSL authentication,
but NSS would balked at my attempt because "The key does not support the
requested operation". It was thought that maybe the PKCS#11 module supported
an old version of Communicator and therefore may have had a subset of
PKCS#11 implemented...

Well, I tried the same PKC#11 module with the latest Communicator (6.2),
which is very cool, by the way.  I first added the PKCS#11 crypto module to
the browser (Edit Preferences->Privcay&Security->Certificates->Manage
Security Devices), and then attempted to access a Web server which requires
client SSL authentication.

The Communicator 6.2 browser behaved just fine: I was able to see the certs
on the card in my certificate list, and more importantly, I was able to *use
the cert on the card for SSL client authentication* at the Web site. I
believe this proves that the PK11 crypto module works just fine with NSS3.x,
correct? Didn't we say Communicator 6.2 uses NSS3.x? In which case why
would'nt my NSS 3.1-enabled app not able to do the same?

BTW, the way I add the crypto module in my NSS-enabled app is via
SECMOD_AddNewModule(modName, libFile, 0, 0 ), where the last 2 parameters
(cipherString and mechanismString) are zero. I believe doing so, means that
NSS will use NSS-provided ciphers and crypto mechanisms, as opposed to the
ones that the crypto module may have implemented.  Maybe I should be adding
the module with different cipherString, mechanismString strings?
More generally,  when a new crypto module is added via the Communicator
interface (Edit Preferences->Privcay&Security->Certificates->Manage Security
Devices), what does NSS use then for cipherString, mechanismString
parameters??

-- P






Reply via email to