Re: TC TrustCenter Root Inclusion Request
Thank you to those of you who have reviewed this request and contributed to the discussion. Your time and commitment to this process is greatly appreciated! To summarize this discussion, there were three areas that were of primary interest. They were: 1) Inclusion of a root that expires in a year and half * The recommendation will be to not include the TC TrustCenter Class 1 CA root, which will be phased out before the end of 2010. 2) Questions about the Class 0 certificates that are part of the CPS. These questions were answered. 3) Questions about the externally-operated subordinate CAs. Information was provided and clarified. There is an externally- operated subordinate CA chaining to the TC TrustCenter Class 2 CA II root, which is used to issue device certificates and email certificates for internal use only. The device name and the email address belong to a company internal domain, so the ownership is guaranteed. It is requested that TC TrustCenter do the following two action items before signing future externally-operated subordinate CAs: 1) Add statements in the TC TrustCenter CP/CPS and in the relevant sub- CA CP/CPS that require that the sub-CA CP/CPS be published when the sub-CA is allowed to issue certificates outside of their company/ organization. 2) Audit the externally-operated sub-CAs against the same criteria as the TC TrustCenter CAs annually. Consider including the externally- operated sub-CAs in the annual audit that a third-party performs against the TC TrustCenter CAs. This concludes the public discussion for TC TrustCenter’s request to add four root CA certificates to the Mozilla root store, as documented in the following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=392024 I will update the bug to summarize the request and recommend that Mozilla approve inclusion of three roots: TC TrustCenter Class 2 CA II, TC TrustCenter Class 3 CA II, and TC TrustCenter Universal CA I. Thanks, Kathleen -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Current algorithm support for Firefox?
albiii wrote: Please get Mozillla's Window Snider involved. That powerhouse of convincing attitude can make anything happen ! :-) Note that Window no longer works for Mozilla: http://blog.mozilla.com/security/2008/12/10/leaving-mozilla/ Frank -- Frank Hecker hec...@mozillafoundation.org -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
RSA AES Cipher problem with JSS/NSS
Hello, I am Mozilla-JSS as the provider in my Java application which is a SSL client connecting to OpenSSL based SSL Server. I am using the cipher suite TLS_RSA_WITH_AES_128_CBC_SHA and we are using TLSv1.0 as the SSL protocol. I get this exception when I try to connect to the server. Server has a self signed RSA based certificate. What I thought was premaster secret key is generated by the Client and encrypt using the public key of the certificate so that Server will decrypt using its private key. Can some one tell me what I am missing here and what this exception means? javax.net.ssl.SSLKeyException: RSA premaster secret error at com.sun.net.ssl.internal.ssl.PreMasterSecret.init (PreMasterSecret.java:86) at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverHelloDone (ClientHandshaker.java:439) at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage (ClientHandshaker.java:132) at com.sun.net.ssl.internal.ssl.Handshaker.process_record (Handshaker.java:334) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord (SSLSocketImpl.java:805) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake (SSLSocketImpl.java:1046) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake (SSLSocketImpl.java:1059) at com.fhp.ems.main.TestSecurity_SSL.testSSL (TestSecurity_SSL.java:218) at com.fhp.ems.main.TestSecurity_SSL.main (TestSecurity_SSL.java:69) Caused by: java.security.InvalidKeyException: Invalid key type: org.mozilla.jss.pkcs11.PK11RSAPublicKey at org.mozilla.jss.provider.javax.crypto.JSSCipherSpi.importKey (JSSCipherSpi.java:123) at org.mozilla.jss.provider.javax.crypto.JSSCipherSpi.engineInit (JSSCipherSpi.java:161) at org.mozilla.jss.provider.javax.crypto.JSSCipherSpi.engineInit (JSSCipherSpi.java:270) at javax.crypto.Cipher.init(DashoA13*..) at com.sun.net.ssl.internal.ssl.JCE_RSACipher.encryptInit (RSACipher.java:76) at com.sun.net.ssl.internal.ssl.PreMasterSecret.init (PreMasterSecret.java:83) ... 8 more -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: RSA AES Cipher problem with JSS/NSS
ksreedha...@gmail.com wrote, On 2009-04-01 17:54: Hello, I am [using] Mozilla-JSS as the provider in my Java application which is a SSL client connecting to OpenSSL based SSL Server. You haven't reported version information, such as: - version of JDK/JRE - version of JSS - version of NSS It's possible that you have a version mismatch of some sort. I am using the cipher suite TLS_RSA_WITH_AES_128_CBC_SHA and we are using TLSv1.0 as the SSL protocol. I get this exception when I try to connect to the server. Server has a self signed RSA based certificate. I have rearranged the stack below, so that it appears as one continuous stack, with the first (or root cause) exception at the top. I thought premaster secret key is generated by the Client and encrypt using the public key of the certificate so that Server will decrypt using its private key. That's correct for the cipher suite TLS_RSA_WITH_AES_128_CBC_SHA. Can some one tell me what I am missing here and what this exception means? The first exception reported in this stack, namely: java.security.InvalidKeyException: Invalid key type: org.mozilla.jss.pkcs11.PK11RSAPublicKey says that the failure occurred when trying to encrypt the pre-master secret with the RSA public key. The exception reports that the key it was given as the pre-master secret, to be encrypted with the server's RSA public key, was actually not a pre-master secret, but rather was an RSA public key. The code that threw the first exception may be seen at http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/jss/org/mozilla/jss/provider/javax/crypto/JSSCipherSpi.javarev=1.7mark=103,106,123-124#103 at org.mozilla.jss.provider.javax.crypto.JSSCipherSpi.importKey (JSSCipherSpi.java:123) at org.mozilla.jss.provider.javax.crypto.JSSCipherSpi.engineInit (JSSCipherSpi.java:161) at org.mozilla.jss.provider.javax.crypto.JSSCipherSpi.engineInit (JSSCipherSpi.java:270) at javax.crypto.Cipher.init(DashoA13*..) at com.sun.net.ssl.internal.ssl.JCE_RSACipher.encryptInit (RSACipher.java:76) at com.sun.net.ssl.internal.ssl.PreMasterSecret.init (PreMasterSecret.java:83) Consequently, it was unable to create an RSA-encrypted pre-master secret (also know as the RSA pre-master secret), and this is what the second exception is complaining about. (which caused) javax.net.ssl.SSLKeyException: RSA premaster secret error at com.sun.net.ssl.internal.ssl.PreMasterSecret.init (PreMasterSecret.java:86) at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverHelloDone (ClientHandshaker.java:439) at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage (ClientHandshaker.java:132) at com.sun.net.ssl.internal.ssl.Handshaker.process_record (Handshaker.java:334) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord (SSLSocketImpl.java:805) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake (SSLSocketImpl.java:1046) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake (SSLSocketImpl.java:1059) at com.fhp.ems.main.TestSecurity_SSL.testSSL (TestSecurity_SSL.java:218) at com.fhp.ems.main.TestSecurity_SSL.main (TestSecurity_SSL.java:69) Maybe Glen can tell us more about diagnosing this failure. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Allocator mismatches
Benjamin Smedberg wrote, On 2009-03-31 08:35: On 3/30/09 5:34 PM, Nelson B Bolyard wrote: The problem is mixing DLLs that use standard VCRT with those that use Mozilla's modified VCRT. As long as there are bugs in the browser of the sort that Neil has found, developers of libraries upon which the browser depends, who develop with the free version of MSVC, CANNOT test their own library builds against Firefox builds from Mozilla. On the contrary, extension developers certainly *do*, because the bugs that Neil has found rarely affect extension developers. Wonderful. But this has no relevance to NSS or NSPR. In the other cases, we should just fix the bug, which is (I think) why Neil posted originally. I wish him Godspeed in fixing (or even filing) those bugs. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
