Re: Fedora Crypto Consolidation
Arshad Noor wrote: Given that the Fedora community is embarking on an effort to consolidate crypto keystores and libraries, it would make sense to take the needs of the Java community also into consideration in the design and implementation. [...] 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. I don't believe this is the best option. Since java 1.5, there is a pkcs#11 base JCE included by default in the SUN JVM. It works with NSS, if you configure correctly some compatibility options : http://java.sun.com/javase/6/docs/technotes/guides/security/p11guide.html#NSS So the best choice would be to rely on that instead, and see if it's possible to have the sun java rpm package preconfigured correctly to use it and to make it the default JCE. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Fedora Crypto Consolidation
I am familiar with the SunPKCS11 Bridge, Jean-Marc. However, I believe that that is all it is - a bridge connecting two different environments. I don't deny that the bridge does work, but it will always be constrained by the fact that the two sides on either side of the bridge may evolve at different rates and in different directions - leading to development and operational headaches for everyone. If the Fedora community is taking the visionary step of consolidating the different crypto-stores in the open-source community, then there is added benefit to including the Java community natively rather than through a bridge. Many Linux developers are also Java developers - and vice-versa - and they would appreciate that they do not have to deal with the complexities of the Bridge for a new environment - I can understand the reason to leave things alone for the legacy environment. Opportunities to do the right thing don't come often - PKCS#11 was good, but the community splintered with many crypto-stores despite PKCS#11. Sun had to come up with something that worked across all Java platforms - hence JKS. Microsoft continues to crow because of their unified key-store in CAPI. FCC is good; but the open-source community now has the opportunity to bring all open-source crypto-stores together - on Linux and Java. Whatever design is created for FCC, if they take the Java community into consideration (and create a JSR for future evolution of the key-store), this will ensure that FCC and the JCE environment stay in lock-step. Arshad Noor StrongAuth, Inc. - Original Message - From: Jean-Marc Desperrier [EMAIL PROTECTED] To: dev-tech-crypto@lists.mozilla.org Sent: Wednesday, September 12, 2007 6:22:02 AM (GMT-0800) America/Los_Angeles Subject: Re: Fedora Crypto Consolidation Since java 1.5, there is a pkcs#11 base JCE included by default in the SUN JVM. It works with NSS, if you configure correctly some compatibility options : http://java.sun.com/javase/6/docs/technotes/guides/security/p11guide.html#NSS So the best choice would be to rely on that instead, and see if it's possible to have the sun java rpm package preconfigured correctly to use it and to make it the default JCE. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
PKCS #11 sucks. Re: Fedora Crypto Consolidation
A cryptographic subsysten based on C and not having a registration facility is not a solution for the 21st century. AR - Original Message - From: Jean-Marc Desperrier [EMAIL PROTECTED] Newsgroups: mozilla.dev.tech.crypto To: dev-tech-crypto@lists.mozilla.org Sent: Wednesday, September 12, 2007 15:22 Subject: Re: Fedora Crypto Consolidation Arshad Noor wrote: Given that the Fedora community is embarking on an effort to consolidate crypto keystores and libraries, it would make sense to take the needs of the Java community also into consideration in the design and implementation. [...] 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. I don't believe this is the best option. Since java 1.5, there is a pkcs#11 base JCE included by default in the SUN JVM. It works with NSS, if you configure correctly some compatibility options : http://java.sun.com/javase/6/docs/technotes/guides/security/p11guide.html#NSS So the best choice would be to rely on that instead, and see if it's possible to have the sun java rpm package preconfigured correctly to use it and to make it the default JCE. ___ 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
Fedora Crypto Consolidation
Bob, I am gratified to see this effort on Fedora - it is sorely needed. However, there is one area of coverage that is missing in this effort: that of Java developers. As you know, Java has its own keystore and APIs for the same functions (with some limitations) that NSS offers. While Java developers have to currently deal with multiple keystores (beyond the JKS), it at least gives them some consistency across platforms - which is a great benefit. Given that the Fedora community is embarking on an effort to consolidate crypto keystores and libraries, it would make sense to take the needs of the Java community also into consideration in the design and implementation. While you will rightly point out that JSS provides that capability today, unfortunately, the JSS API is quite different from the JCE API and requires application-level porting. 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. I'm looking forward to seeing this work come to fruition; you can count on my support. Arshad Noor StrongAuth, Inc. Robert Relyea wrote: It's part of the Fedora Crypto Consolidation project: http://fedoraproject.org/wiki/FedoraCryptoConsolidation ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Fedora Crypto Consolidation
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 smime.p7s Description: S/MIME Cryptographic Signature ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Fedora Crypto Consolidation
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
