Steve/Bob, The problem with JSS is that there are JSS-specific calls in the code that are required to make it work; for example, the code you pointed out has the following:
107 CryptoManager.InitializationValues vals = new 108 CryptoManager.InitializationValues (dbdir ); 109 vals.removeSunProvider = true; 110 CryptoManager.initialize(vals); 111 manager = CryptoManager.getInstance(); 112 manager.setPasswordCallback( new FilePasswordCallback(file) ); For someone who's trying to write JCE Provider-independent code, no matter how small these sections are, they're a maintenance headache. Contrast that with the approach that allows an end-user to switch providers by just modifying values in property files (without the need for if-then-else sections that check for provider-types). While Sun does provide the SunPKCS11-Bridge (and SunCAPI- Bridge) to hide the provider-specific configuration, it does add a level of complexity that can be a bear to debug when things go wrong. This is why I expressed the desire to see something come out of the Fedora Crypto Consolidation (FCC) effort that will make it possible for Java developers to write applications that do not stray from the JCE API *and* will still work with the FCC implementation seamlessly without the need for a PKCS11/CAPI Bridge. Arshad Noor StrongAuth, Inc. Steve Parkinson wrote: > Robert Relyea wrote: > >>Arshad Noor wrote: >> >>>What would be ideal is for JSS to evolve into becoming >>>just another pluggable JCE Provider and hide the access >>>to the consolidated Fedora crypto keystore/library >>>behind that interface. You will then be doing two >>>communities a great service. >>> >> >>IIRC, JSS is a JCE provider, as well as providing an API. One of the >>problems we have with JSS open source is the difficulty allowing the >>community to build and load that functionality, because you need a >>certificate provided by Sun to do so... so ironically JSS as a JCE >>provider can work in fedora with gcj, but not with the Sun jvm. (Of >>cource the Red Hat RHEL version is so signed, so can be used as a >>provider in all JVMs. >> >>Steve/Glenn have I represented things correctly here? >> >>bob > > > I think so. One more thing is that the IBM JRE is in the same boat as > the Sun JRE, in that it also requires them to be signed. > > Here's an example of using JSS via the JCE/JCA api to sign something: > http://lxr.mozilla.org/security/source/security/jss/org/mozilla/jss/tests/JCASigTest.java > > Steve > _______________________________________________ > 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
