Let me explain you my motivation: I have client java 1.6 application, which runs on windows platform. The server java 1.6 application runs on Solaris 10 and should be FIPS140-2 compliant. Thus, all crypto on server side should pass through the tunnel of PKCS#11 provider crypto API to NSS 3.11.4, which is FIPS 140-2 compliant. The client server communication is performed by RMI over SSL. Therefore, we should keep private/public key pair both on client side and on server side. The client keeps both keystores (private and public) on JKS format files (they can be created with certificate, if needed for future NSS issues) , and the server should keep it in NSS db in FIPS mode (otherwise it won't be FIPS 140-2 compliant). Still, both application need to share their public keys so that Java applications on both sides will manage to instantiate SSL context for socket traffic over SSL. How would you suggest me to design my RMI traffic, so that I'll be able to preserve my FIPS 140-2 compliancy mode? Thanks Yevgeniy
-----Original Message----- From: Nelson B Bolyard [mailto:[EMAIL PROTECTED] Sent: Monday, June 23, 2008 23:45 To: mozilla's crypto code discussion list Subject: Re: Importing exporting JKS key to NSS db Yevgeniy Gubenko wrote, On 2008-06-23 12:47: > I don't know how to extract specificly public key after I > used the following command: > > certutil -G -n srv -k rsa -g 1024 -z seed -f pwdfile.txt -d . > > which should have created me public/private key pair. > The second problem is: after I have created JKS public and private files, > what are the right commands to use to convert it to PKCS#12 format and > how to import it from PKCS#12 file to NSS database? I had some try, but > it did not work, therefore I want to consult what is the right way from > the scratch. As I understand it, you're trying to use bare public and private keys without certificates. Perhaps you're trying to do something like SSH using NSS. NSS isn't intended to be used in that manner. While NSS's lowest level crypto functions are quite capable of performing in that fashion, all the higher layer functionality in NSS is designed around the use of certificates in certificate hierarchies. All of the crypto functions accessible through JavaScript in the browser likewise are designed around the use of certificates. NSS doesn't store public keys, except in certificates or certificate requests. NSS doesn't name private keys, but rather names certificates and accesses private keys indirectly, starting with the name of the certificate that bears the public key corresponding to the private key. certutil's -G command is a QA test feature that merely serves to test key generation functions in NSS. Perhaps we should eliminate the -G command. It is quite useless for any other purpose than QA tests, because, once the key pair is generated, the public key is not output in any way and is not stored. The private key generated by certutil -G becomes an "orphan". The certutil program offers no way to do anything more with the bare private key generated with certutil -G. Most people who think they want to use certutil -G actually want to use certutil -R. certutil -R does all that is done by certutil -G, and more. After generating the key pair, it outputs the public key in a certificate signing request, from which a certificate can be issued. In summary, if you want to use RSA keys in Mozilla products, plan to use certificates rather than bare keys. This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
