Re: Importing exporting JKS key to NSS db
Yevgeniy Gubenko wrote: 1.export public key from Solaris to Windows in JKS format 2.import public key from Windows to Solaris into NSS database I would export as PKCS#12 format and import that to NSS cert DB. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: New SSL warning
Hi, Please read the thread about Debian keys first: I did (now completely), but most of it seems to be a discussion about CAs (not) revoking keys. As I understand it, if the CA does use only a normal CRL (and not OCSP), firefox won't care. At least the proof-of-concept attack on the akamai key still worked. You can try to edit the trust flags of that see (remove all trust) and when encountering a site with a certificate from that CA to add an exception. The problem with this is that the CA is then completely ignored (as it is basically untrusted), so I cannot see if the cert is really issued by that CA or a fake CA certificate with a different key but the same name. Wild cards go as well with the exceptions. I did not find a way to do this, can you tell me where to look? I think that if the Mossad wanted a fake cert, they would get it fairly quickly, one way or the other. there is no such a thing, never was and never will be! First, I would like to make clear that I am quite sure that no CA would create a fake cert just because an intelligence agency simply asked to do so. But I assume(d), that if a powerful intelligence agency wants to achive something like this, they will find a way (for example by threatening an employee or simply faking identification documents, or just intercepting the verification e-mail that is probably transfered via unsecured SMTP). I just picked the mossad because I considered it the most powerful and capable agency, and the Startcom CA as I assumed that it would be the easiest thing for the mossad to do it in its own country. If something like that happened, it would not be the fault of the CA, I don't think there is anything the CA can do against this. I do NOT say that Startcom is insecure because it is from Israel (actually I might get my cert from Startcom as soon as I need one). I think it can happen anywhere in case a capable intelligence agency decides that it wants to get a fake cert. (Hopefully there aren't any trusted CAs in countries with totalitarian governments, as it would probably be quite easy there) About the Verisign thing: In the USA, the new counter-terrorism regulations (some of which seem to be secret) could force a CA to cooperate, but I will gladly accept the opinion of someone who has more experience than me. I guess the Mossad doesn't need the services of StartCom nor does any party of interest use certificates issued by a legitimate CA either. That might be the main reason why not to worry too much about the scenario. But it was just an example, other failure situations are possible, so I think a lock in feature would be useful for advanced users anyway. (AFAIK the only reason why the CAcert root certificate was not broken because of the debian problem is that it was generated before the error was introduced). Regards, Jan -- Please avoid sending mails, use the group instead. If you really need to send me an e-mail, mention FROM NG in the subject line, otherwise my spam filter will delete your mail. Sorry for the inconvenience, thank the spammers... ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
https flow
Hello, I want to overwrite default mozilla 1.9 behavior in https flow. I want to be informed about certificates (especially bad). I'll show my own certificate dialogs to user and user will decide if accept certificate or not. In mozilla 1.8 I used nsIBadCertListener interface to do above. In mozilla 1.9... there is no such interface. There is nsIBadCertListener2, but it exports only one method that inform about certificate problem. No matter what will happen in this method ssl connection will be broken. Is there any way to change default https flow in new mozilla? Please help. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: New SSL warning
Jan Schejbal: I did (now completely), but most of it seems to be a discussion about CAs (not) revoking keys. As I understand it, if the CA does use only a normal CRL (and not OCSP), firefox won't care. At least the proof-of-concept attack on the akamai key still worked. Yes, as indicated CRL fetching is in the works. Wild cards go as well with the exceptions. I did not find a way to do this, can you tell me where to look? Nope, I'm mistaken. I thought it would work, but it doesn't. First, I would like to make clear that I am quite sure that no CA would create a fake cert just because an intelligence agency simply asked to do so. Thank you :-) But I assume(d), that if a powerful intelligence agency wants to achive something like this, they will find a way (for example by threatening an employee or simply faking identification documents, or just intercepting the verification e-mail that is probably transfered via unsecured SMTP). Oh well, any relevant ISP can do that, it doesn't have to be the FBI, CIA, MI5 or the Mossad. Obviously that has nothing to do with the country of origin (as you indicated in the previous post about Chinese CAs - or Israeli for that matter). The argument itself isn't really valid I think. But also needless to say that this would be a criminal offense which could be persecuted accordingly. I just picked the mossad because I considered it the most powerful and capable agency, and the Startcom CA as I assumed that it would be the easiest thing for the mossad to do it in its own country. If something like that happened, it would not be the fault of the CA, I don't think there is anything the CA can do against this. Except secure SMTP connections and additional flagging and verifications, which StartCom does even in the Class 1 (domain validated) settings. It's certainly not 100% foolproof, but the best it can get. (actually I might get my cert from Startcom as soon as I need one). Be my guest... About the Verisign thing: In the USA, the new counter-terrorism regulations (some of which seem to be secret) could force a CA to cooperate, but I will gladly accept the opinion of someone who has more experience than me. I can't answer for them obviously... That might be the main reason why not to worry too much about the scenario. But it was just an example, other failure situations are possible, so I think a lock in feature would be useful for advanced users anyway. (AFAIK the only reason why the CAcert root certificate was not broken because of the debian problem is that it was generated before the error was introduced). A compromised root is an entirely different story! But they aren't in NSS so we don't have to worry about that. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Debian Weak Key Problem
Gervase Markham: Rob Stradling wrote: That is now old news. I'm pleased to announce that... snip applause Gerv StartCom has concluded today the revocation of all vulnerable keys which were signed by any of our roots, respectively intermediate CA certificates. Several notifications were sent to the subscribers. (Gerv, no applause needed...thanks!) For the statistics: 1.57 % weak keys out of all currently valid certificates were forcefully revoked. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Update on DigiNotar and Entrust
Frank Hecker wrote: 3. Find some other way to get NSS not to recognize DigiNotar certs for email, perhaps in combination with some action by Entrust and/or DigiNotar. For example, one idea is to have end users of DigiNotar certs reconfigure their email clients to have cert chains that terminate in the DigiNotar Root CA root; unfortunately that's not really workable IMO (since every cert holder would have to do this). Another idea is to have Entrust revoke the DigiNotar Root CA intermediate cert; however as I understand it that would have no effect whatsoever, as NSS doesn't check for revocation of CA certs (except in the EV case). There's perhaps a possibility that adding the DigiNotar Root CA intermediate cert to the preloaded cert list would help, but that's unclear at this point given the current state of NSS. Try this as a solution: Have entrust reissue the diginotar intermediate with the appropriate extended key usage which restricts email usage. Include that intermediate in our root store. The reason NSS selects the current intermediate over the root is because the intermediate is newer (IIRC). 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: Importing exporting JKS key to NSS db
Thanks Michael for your reply First of all, 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. Yevgeniy -Original Message- From: Michael Ströder [mailto:[EMAIL PROTECTED] Sent: Monday, June 23, 2008 11:40 To: dev-tech-crypto@lists.mozilla.org Subject: Re: Importing exporting JKS key to NSS db Yevgeniy Gubenko wrote: 1.export public key from Solaris to Windows in JKS format 2.import public key from Windows to Solaris into NSS database I would export as PKCS#12 format and import that to NSS cert DB. Ciao, Michael. 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
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. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: certutil or PKI for NSS 3.11.9
Nelson, I think you may want to qualify your message in this paragraph, so as to not mislead people who don't understand PKI very well. As I'm sure most people on this list know, every Root CA certificate is a self-signed certificate. There is nothing inherently insecure about such certificates, or the ones they issue. It is the policies, procedures and technology used to protect the components of a PKI that make them secure or insecure (as some recent discussions on this list are highlighting). What makes self-signed *end-entity* certificates insecure is that RPs are required to make trust decisions about the certificate(s) with little or no knowledge about them. However, there are many situations where self-signed end-entity certs may be acceptable even in Production: point-to-point security between servers where the client and server are controlled by a single individual/group. Since this individual/group is/are the creators and relying parties themselves, as long as the components of their infrastructure are well-protected, these self-signed certs could be deemed secure. That said, any infrastructure that used PKCS components is better served building a PKI - no matter how small it may be - to manage the certs and the procedures used in managing them. Additionally, they should also use some hardware crypto module - smartcard, TPM or HSM - to protect the private-key of their certificates. If they do these two things and follow their self-directed policies and procedures with reasonable diligence, then I would argue that there is no difference between self-signed or public-CA issued certs. Arshad Noor StrongAuth, Inc. Nelson B Bolyard wrote: The big warning paragraph that you quoted (and I snipped) is really trying to warn against the use of certutil (or any tool that produces self-signed certificates) for certificate issuance in production environments. The page is explaining how to setup a very small scale CA using certutil for use in very small scale test environments. The warning is intended to be If you use self-signed server certs in production, you'll be sorry!. It doesn't say that very well. The warning sounds like it's saying certutil does a bad job of issuing self-signed certs, but that's not the issue. Some people read it as if it is saying don't use certutil for this, but instead use some other tool like OpenSSL, and that's exactly the wrong message. The message is: don't use self-signed server certs in production. The tool that makes them doesn't matter. Self-signed certs are bad for production. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: NSS 3.12 is released
On Jun 24, 2008, at 9:41 AM, Wan-Teh Chang wrote: On Thu, Jun 19, 2008 at 2:11 AM, Jean-Marc Desperrier [EMAIL PROTECTED] wrote: But Firefox 3.0 does not make use of the SQLite support, right ? Quite a pity ... You're right. I added a note to the NSS 3.12 Release Notes to clarify this point: http://www.mozilla.org/projects/security/pki/nss/nss-3.12/nss-3.12- release-notes.html#Introduction Wan-Teh, Do you think we'll get SQLite support in for 3.1 or perhaps a dot- release? Gen Kanai ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
