Thank you, Wan-Teh. Yes, we chose not to use JSS directly for a couple of reasons:
1) The JSS interface does not map closely to the JCE in J2SE5 and required us to write JSS-specific code. This was something we wanted to avoid, to keep our focus above the abstraction layer provided by JCE. 2) We wanted to take advantage of the excellent work done by the people at Mozilla and Sun on the PKCS11 interface and the SunPKCS11 bridge, respectively, and minimize our reinventing the wheel. I believe we have achieved both these objectives. StrongKey uses no provider-specific code directly and with just a change in the properties file of the application, it can use either the SunJCE, NSS, BouncyCastle, one specific vendor's smartcard or one-specifc vendor's HSM for crypto capabilities. (We're integrating most major HSMs into the software). With JDK6, we expect to go one step further by using the new SunCAPI bridge and using Windows-specific drivers of CSP's for which no PKCS11/JCE interface exists. Arshad Noor StrongAuth, Inc. P.S. If you believe that JSS is evolving to map to the JCE interfaces completely, and if there are specific advantages to going to JSS directly instead of the SunPKCS11 bridge, do let us know. We would be interested in hearing them. Thanks. Wan-Teh Chang wrote:
Arshad, Congratulations on the product launch. You said that your product, StrongKey, specifically uses the NSS libraries through the SunPKCS11 Bridge in the JCE. I'd like to know why you don't use the default JCE provider, and why you don't use JSS or the Mozilla-JSS provider as the interface to NSS. You are only using the "softoken" PKCS #11 library (libsoftokn3.so) of NSS, right? Wan-Teh _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
_______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
