On 11/10/2010 09:37 AM, Andre Zepezauer wrote: > Hello Douglas, > > you should check if NSS does support ECDSA. If it does, then it should > verify the users certificate on its own. Calling a PKCS#11 provider for > doing it, is some kind of abuse. (See quotation below) I varies with builds. Most Linux builds do not have internal support for ECDSA, though NSS itself recognizes it. If a PKCS #11 module that supports it is loaded, NSS will use that PKCS #11 module to do all the EC operations. I think that is what you are seeing. > But if NSS tries to offload the verification to OpenSC, because it > doesn't has support for ECDSA, then you are in trouble. This is because > the recipient of your signed e-mail also would need OpenSC for > verification. Not practical I think. I'm presuming if the recipient has an ECDSA certificate, then they can do ECC (either through some native implementation, or because it has ECC plugged in). > PKCS#11 Section "6.2 Design goals": > "Cryptoki was intended from the beginning to be an interface between > applications and all kinds of portable cryptographic devices [...] It is > not the goal of Cryptoki to be a generic interface to cryptographic > operations or security services [...]" While that is true, it has been functioning as a generic interface for over 15 years;).
That being said, there is no requirement of OpenSC to function as a generic interface. If you need ECC with versions of NSS that does not supply it, there is nothing that says OpenSC must supply it, particularly if it's not in the OpenSC design point. If you need such a thing, providing your own software implementation of ECC is possible, and it's also possible to tell NSS to prefer using your software version rather over all others. bob > Regards > Andre > > On Wed, 2010-11-10 at 10:56 -0600, Douglas E. Engert wrote: >> Does OpenSC PKCS#11 support the creation of session objects? >> Has anyone looked at doing this? >> >> I bring this up as I am testing EC mods to OpenSC using >> Thunderbird to sign e-mail as a test. In my case, the user certificate >> is using ECDSA with a named curve, and the test CA is also using >> ECDSA to sign the user's certificate. >> >> Thunderbird 3.1.4 with NSS-3.12.x (x is at least 3) on Solaris 10 >> tries to create a session public key, where the key is the public >> key of the CA. I think NSS is going to use this public key to verify >> the signature of the user's certificate asking the OpenSC PKCS#11 >> ECDSA to do the verify. Depending on the card, this may have to be >> done in software. >> >> See the attached edited PKCS11-SPY output, showing mechanisms, >> open session, session info, and failed create object. Not shown >> are pin/login, and retrieval of the user certificate. >> >> PKCS#11 2.20 says : Table 4 "R/O Public Session" >> "The application has opened a read-only session. The application >> has read-only access to public token objects and read/write access >> to public session objects." >> >> I don't think NSS does this if the CA is using RSA to sign >> the certificates, and I will try that next. (But eventually >> some CA will start using ECDSA to sign certificates.) >> >> Even if the ECDSA verify was to be added to OpenSC PKCS11, >> to be done in software, I would expect it might have to use >> OpenSSL to do the verification. >> >> _______________________________________________ >> opensc-devel mailing list >> opensc-devel@lists.opensc-project.org >> http://www.opensc-project.org/mailman/listinfo/opensc-devel > _______________________________________________ > opensc-devel mailing list > opensc-devel@lists.opensc-project.org > http://www.opensc-project.org/mailman/listinfo/opensc-devel
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
