Re: Mail Security Spec 2
Steve, Dr S N Henson wrote: Frederick Roeber wrote: I'm of the opinion that encryption and signing should be turned on by default Turning on signing by default might be dangerous, not everybody is comfortable with a Legally Binding Signature on every random note they send. (Plausible deniability can be a good thing!) Not to mention being flamed in many mailing lists or newsgroups. Spammers would also love that. How would they love it ? I'm not sure if it would be such a problem actually. The auto signing feature could be taken one step further. Eg. there could be a new type of e-mail filter that for unsigned or unverified emails. At some point in the future, I would like to set the action for that filter in my e-mail client to automatically move all matching messages to the trash. I don't know about you, but I just don't think anonymous e-mails are worth replying to, and this type of filter would automatically get rid of all anonymous correspondence, most notably spam, because the spammers would face legal charges if their emails contained a legally binding signature. That would of course assume that there are worthy CAs out there that I can trust in my browser to do a good job of verifying users when issuing certs ...
Re: problem via STDIN cmsutil
Alex, [EMAIL PROTECTED] wrote: First time browsing this list so apologies if this has already been noted. Using nss-3.3 precompiled Linux binaries cmsutil did not produce verifiable signitures when the entity was piped in via STDIN. However, when using the -i switch the signiture verifies correctly. Tested using signver, MS Outlook and Mozilla 0.9.5. Regards, Alex [EMAIL PROTECTED] Please see the bug at http://bugzilla.mozilla.org/show_bug.cgi?id=95262. There is a fixed smime perl script attached. Try it and see if it works for you. It's not checked in to any version of NSS yet as some other issues remain.
Re: How to debug my pkcs11 token dll in Netscape CMS
hooway wrote: We are making a PKCS11 token dll for CMS server. But we met some problems. and cause windows shut down. We want to debug our dll to find the reason. But how to do it under CMS server. It's always working as a NT Service. Is there any method to force it working not in Service mode. I don't know if there is a way to make CMS not run in service mode, but you can still attach to an NT service in order to debug your code. As long as you are logged in as a user with sufficient local priviledges (ie. administrator), you can bring up the task manager, select the process, click mouse button 2, and select debug. Then you can use the debugger as you normally would, except you can't restart the program from the debugger if you stop it - you'll have to wait for the service to restart, and reatach, using the above procedure I described. You will still be able to save your breakpoints though. If the problem in your module happens on initialization, you will probably want to add some sort of sleep loop into your code so that you can attach and interrupt it by reassigning the value of a variable. You could also call DebugBreak in your init code, which will cause a pop-up dialog to come up on the machine, and let you attach to the process. Then just skip the Int 3 call and debug your code after it.
Re: SEC_ERROR_LIBRARY_FAILURE too vague of an error message
Robert, Robert Wagner wrote: I have a working client/server application that is using NSS 3_3_1_RTM. One check my application does is verify if the password supplied is correct. After I initialize and configure all of NSS, my application calls PK11_CheckUserPassword. When you call PK11_CheckUserPassword, are you using the NSS internal database as a token, or an external token (eg. smartcard) ? PK11_CheckUserPassword returns with SEC_ERROR_LIBRARY_FAILURE regardless if the password is correct or not. PK11_CheckUserPassword accepts two arguments: slot and password. Both arguments are viable before the call is made. Yet if I ignore the failure, everything else works fine (assuming the password is correct). Is it possible that you have some other piece of code in your program that logs you in to the token ? The question is why is NSS happy but PK11_CheckUserPassword isn't? Possibly it is a bug in the PKCS#11 module you are using. Look at pk11err.c, specifically the implementation PK11_MapError() . This will show you the error codes returned from the token that end up mapping to SEC_ERROR_LIBRARY_FAILURE . This mapping is done so the higher levels of code in NSS can take proper action based on categories of errors. You could set a breakpoint within PK11_MapError to see the exact PKCS#11 error code returned from the module.
Re: crlutil help
Bonny, bonny joy wrote: hi all I am working on mozilla's nss code. I have some trouble on using crlutil.eventhough i am using a crlv2 it is giving an error message invalid format .Is this the error with the crlutil or the decoding code in the implementation. A few things to check : - there were problems with the CRL code in the tip of NSS (3.4 beta) before last week, but they have been resolved. If you are using the latest code, please update your tree and rebuild it . That might solve your problem. If you are using a release of NSS 3.3, then that's not the issue as the problem did not exist. - make sure that the CRL you are importing is stored in binary DER format. If that's not the case, then it won't be recognized by crlutil. - you must have the CA cert that the CRL applies to in your cert database, otherwise the CRL will be rejected. You can add that cert to your cert7.db using certutil. If all that still fails, you'll have to debug the code. The function to check is CERT_ImportCRL. You should be able to easily tell from a high-level which step failed.
Re: Cleaning up an NSS build
Patrick, Patrick wrote: Hello, What command to execute to clean up *all* of an NSS build? I built NSS on one platform (HPUX11) and now want to use the same dir structure (/mozilla) to build NSS on another platform (SunOS5.8) However it seems the 2nd build did not create the expected SunOS5.8*.OBJ output directories...Only the HP-UXB*.OBJ output directories from previous build remain...Can one use the same mozilla dir tree to do 2 successive builds on 2 different platforms? (The mozilla dir tree is shared across both platforms via nfs) Yes, you can share the mozilla tree between platforms, and that's the way we typically work. To get rid of a build, go to mozilla/security/nss and do a gmake clobber_all . Similarly, gmake nss_build_all will do the full build. This will only delete or build the directories for the platform you are currently running gmake on . The other platform subdirectories will be left untouched.
Re: NSS build on Solaris
Amlan Haldar wrote: Has anyone built NSS on SunOS 5.8 with Forte C++ with update 2 ? I am having problems. Amlan. I build it regularly on SunOS 5.8 with Force C++ update 1 . Did you ever build with update 1 successfully in the past ? It would help if you would specify what problems you encountered with building on update 2.
Re: nss building on WIN2k
Hi, bonny joy wrote: hello I have a question on NSS building on WIN2k can i buils NSS 3.2.1 on win2k i tried but the following error is coming Microsoft (R) Segmented Executable Linker Version 5.60.339 Dec 5 1994 Copyright (C) Microsoft Corp 1984-1993. All rights reserved. LINK : fatal error L1022: response line too long I think somehow you have the wrong version of the linker. The Segmented executable linker looks highly suspicious. It might be a linker for 16-bit protect mode, such as an old Microsoft linker for 16-bit OS/2 (1.x) or for 16-bit Windows (3.x). The linker date of 1994 should also give you a hint that it might not be compatible with Win2K. The linker I have, which works to build NSS on Win2K, is : Microsoft (R) Incremental Linker Version 6.00.8447 Copyright (C) Microsoft Corp 1992-1998. All rights reserved. -- Except for the lack of debugging and the ps thing, [Linux] kernel threads are generally fine right now. And if you're not too fussed about the more fiddly details of POSIX threads, and your application doesn't spend most of its time in thread creation, then LinuxThreads is great too. Linux-Kernel archive
Re: Verisign CA Certs missing from Mozilla 1.0 RC1?
Christian, Christian Schulte wrote: Robert Relyea wrote: My guess is the certificate in question is a secondary CA signed by a primary. The problem is that gtoc.iss.net is probably misconfigured. It should send the secondary certificate with it's server certificate. Their misconfiguration is masked on IE because IE throughs every CA cert it finds into it's permament certificate store. Daniel Kluge wrote: Hello there, I was just visiting https://gtoc.iss.net/, which gives me an 'Unknown Certificate Signer' or so error. This is a problem with the https://gtoc.iss.net SSL server configuration. We see a lot of these misconfigured servers these days. That server does not transmit the full certificate chain, from leaf cert (SSL server cert with a subject of gtoc.iss.net) to the root Verisign cert, and the intermediate verisign certificate. Unlike IE, Netscape Communicator and Mozilla do not save the intermediate certificates into the database, in order not to grow the database indefinitely every time you visit a new SSL web site. Only the root certificates are kept persistently (and actually they are now in a PKCS#11 module). The SSL protocol specifies that the server must present its entire certificate chain to the client, but this server is not doing so, and therefore Mozilla cannot verify it. This not a mozilla bug. The solution is for the system administrator to correct the server configuration. -- Except for the lack of debugging and the ps thing, [Linux] kernel threads are generally fine right now. And if you're not too fussed about the more fiddly details of POSIX threads, and your application doesn't spend most of its time in thread creation, then LinuxThreads is great too. Linux-Kernel archive
Re: PKCS12 decode validate bags failed
Zeke, Zeke wrote: Hi. I have a one simple (?) problem. ;) When I try to export certificate to my smart card, like: pk12util.exe -d .\ -i good.p12 -h GemSAFE Smart Card I see error message: How many certificates and keys does your P12 file contain ? And of what type (signing, encrypting, etc). How did you generate that P12 file ? pk12util: no nickname for cert...not handled pk12util.exe: PKCS12 decode validate bags failed: The user pressed cancel. What's wrong ? Most likely : - your p12 does not have a nickname for the certificate - your certificate does not have a DN NSS needs a nickname to import the certificate, and it doesn't have one. pk12util currently does not have a way to prompt the user for a nickname during the import phase, only for the export phase. You should open an RFE for this in bugzilla, component NSS / tools. In the short term, you should try to regenerate your p12 file so that it has a nickname, or add a DN to your certificate. -- Except for the lack of debugging and the ps thing, [Linux] kernel threads are generally fine right now. And if you're not too fussed about the more fiddly details of POSIX threads, and your application doesn't spend most of its time in thread creation, then LinuxThreads is great too. Linux-Kernel archive
Re: LDAP SSL session reuse/resume
Stuart, Stuart Davidson wrote: I maybe 2 + 2 = 5... but I have the following questions: Do you have any log from your LDAP server showing whether it received the client certificates and accepted them, or if they were rejected ? As Nelson pointed out, the prior traces showed that the failure to communicate over SSL was due to a server requirement for a client certificate. Even if the ssldump shows a client certificate transmitted, the server could still decide to reject that certificate for some reason - such as the certificate's expiration date, a revoked certificate, or other various application-specific checks. -- Except for the lack of debugging and the ps thing, [Linux] kernel threads are generally fine right now. And if you're not too fussed about the more fiddly details of POSIX threads, and your application doesn't spend most of its time in thread creation, then LinuxThreads is great too. Linux-Kernel archive
Re: Selecting which cert to sign with doesn't work
Chris, Chris wrote: I'm working with my smartcard PKCS #11 module and I have 2 certificates available that can be used for signing messages. Both certs are tied to the same e-mail address and have the same subject. How do the certs exactly differ ? By issuer, date, or other ? This may be helpful in determining the cause of the problem. Mozilla lets me pick which one I want to use for signing e-mail (Account Settings-Security) but it only seems to use one of them when it actually performs the signing of the message. No matter which one I pick in the dropdown, it always uses the same one. I assume each of these signing certs has a different nickname, and that's how you are able to select them in the account/settings/security, is that correct ? When you say that it always uses the same one, do you mean that the same cert nickname always appears in the security dialog regardless of which one you selected in the drop-down, or is it at the time that you actually sign the e-mail message that the wrong signing cert is getting used ? If the former, you may be able to work around it by editing the preferences file and set the cert nickname manually (eg. yoursmartcard:yournickname). If the later, there is probably no workaround and you should open a defect. The component would be PSM. Please cc me on that defect. -- Except for the lack of debugging and the ps thing, [Linux] kernel threads are generally fine right now. And if you're not too fussed about the more fiddly details of POSIX threads, and your application doesn't spend most of its time in thread creation, then LinuxThreads is great too. Linux-Kernel archive
Re: Verisign CA Certs missing from Mozilla 1.0 RC1?
Daniel, Daniel Kluge wrote: IE stores not only the root certificates, but also all intermediate certificates, hence it is successful in putting together the certificate chain. IE is only successful in putting together the full cert chain if it already has a copy of the intermediate CA cert stored in its cert database. This can only be done if you have previously visited another secure server that was correctly configured and sent the entire cert chain. This has the effect of hiding IE users the misconfiguration of the server visited the second time, which failed to send part of the cert chain, namely the intermediate CA. And actually as far as the size of those go, a collection of root certificates is much much bigger, than the one with the intermediate certificates, so the bloat theory doesn't quite hold water. That simply isn't true, the potential for bloat is there. Each root CA can issue any number of intermediate CAs, which could issue more, and so forth. The potential growth of the PKI tree is exponential, depending on which sites you visit. It is true that the bloat doesn't exist today, because most CAs only use a few or no intermediate CA certs. However, that may not be the case tomorrow when PKI becomes more widely deployed. -- Except for the lack of debugging and the ps thing, [Linux] kernel threads are generally fine right now. And if you're not too fussed about the more fiddly details of POSIX threads, and your application doesn't spend most of its time in thread creation, then LinuxThreads is great too. Linux-Kernel archive
Re: Selecting which cert to sign with doesn't work
Chris, Chris wrote: When I actually sign the e-mail message is when it picks the wrong cert. It appears to use the first certificate that can be used for signing e-mail versus actually using the one I told it to use. If I reverse the order that C_FindObjects returns the certificates, then Mozilla will switch which one it always uses. This is just like how Netscape 4.x handles them except the order seems to be reversed with respect to which one it always uses. It seems that Mozilla shouldn't work that way since it lets you pick which one to use. When you say that you are returning certificates in C_FindObjects in a certain order, I'm not sure why you are returning more than one. The template that you are receiving from NSS should include a name field with the nickname, so that your module should only return the one certificate that matches the template fully to NSS, and therefore there would be no ambiguity and no possibility for NSS Mozilla to get confused. Are you sure that you are looking at all the fields in the template in your C_FindObjects code, or only some of them ? It might be helpful to compose your mail in mozilla, attach to it with a debugger, then set a breakpoint in your findobjects code, then hit the send button to generate the signature. Your findobjects will get called (probably more than once, due to the way NSS works). Try to find the template that includes a CKA_LABEL of the nickname you configured in mozilla, and see how many token objects you are returning. It should only be one, unless you have several certificates of different types under the same nickname, but that wasn't the case you described. -- Except for the lack of debugging and the ps thing, [Linux] kernel threads are generally fine right now. And if you're not too fussed about the more fiddly details of POSIX threads, and your application doesn't spend most of its time in thread creation, then LinuxThreads is great too. Linux-Kernel archive
Re: Selecting which cert to sign with doesn't work
Chris, Chris wrote: When Mozilla initially starts it does a C_FindObjects (with a max count of 16 or so) for all certificates on the token. I return both certificates at this point because the only search attribute is CKA_CLASS == CKO_CERTIFICATE, no other search attributes are present (the P11 module always searchs on all supplied attributes). Mozilla then continues on and gets various attributes of the certificates (CKA_LABEL, CKA_ID, CKA_SUBJECT, CKA_VALUE, etc.). I can see in my logs all the ID's and labels, each cert has unique CKA_ID's and CKA_LABEL's and Mozilla retrieves the appropriate attributes from each one. Later when Mozilla actually goes to sign a message, it does one FindObjects looking for a CKA_CLASS of CKO_PRIVATE_KEY with a specific CKA_ID. This matches the one private key for the certificate it has determined it should use. It seems to have already chosen which cert to use based on the information gathered above. It then calls C_Sign using that specific key that matches one and only one specific cert. Which key/cert pair it uses depends on the order in which I returned the certificates in that very first C_FindObjects that listed all available certs. Changing the e-mail signing cert in Account Settings-Security appears to have no effect whatsoever on which key/cert pair it tries to use. I can post very detailed logs on the calls into the P11 module if you think that would be helpful. The calls you describe seem like an effect of our cert cache, which code I'm still unfamiliar with. Before you send me your PKCS#11 logs, can you extract your conflicting certs keys from the smartcard, or generate news PKCS#12 files of those certs with identical subjects but different other properties ? If so, can you try importing them into softoken (internal certificate database) and see if the same problem exists with that module ? If yes, it is definitely a bug in either NSS or mozilla. If you can reproduce the problem that way, please open a bugzilla bug against PSM. Please make sure to cc me ([EMAIL PROTECTED]) and attach the PKCS#12 files, and I will investigate. If the problem occurs only in your module but not with softoken, the PKCS#12 files might still be helpful for me. I could try them with another vendor's smartcard.
Re: Someone from Thawte .... help please ?
Michael, Michael Ströder wrote: Ben Bucksch wrote: Julien Pierre wrote: the private key could have been sent to the CA if it required key escrow during enrollment, Eh, but the software (i.e. Mozilla) will clearly and obviously tell me about it in any and all cases, won't it? This would have been also my next question. CMP/CRMF is very powerful and I wonder how client software will keep the user informed what *really* happens... I tested this once with Mozilla and an internal test CA setup for key escrow, and saw the dialog warning about the key escrow and prompting to proceed or not. Typically, if you have dual-key certs (separate signing and encrypting keys), only the encrypting private key will be backed up. It's never a big deal if you lose the signing key, since you will be able to generate a new signing keypair and cert. However, if you lose your private encrypting key, as the original poster did, you will also lose access to all the data you have encrypted with it, such as any S/MIME encrypted e-mails you saved locally. This is a moot point for the at poster who lost the entire profile anyway, but not necessarily for everybody, if only the key got lost, and not the rest. Note that I'm not necessarily advocating key escrow here - I think it somewhat defeats the purpose of encryption - I'm only advocating key backups. It can be a pain for individual users to backup their keys safely, but it is necessary. If smartcards are use, a backup of the keys is usually not possible however if the keys were generated within the smartcard. -- Except for the lack of debugging and the ps thing, [Linux] kernel threads are generally fine right now. And if you're not too fussed about the more fiddly details of POSIX threads, and your application doesn't spend most of its time in thread creation, then LinuxThreads is great too. Linux-Kernel archive
Re: Selecting which cert to sign with doesn't work
Chris, Chris wrote: Sure, I can take a look when I get a chance. If you have some pointers of where to look first that might be helpful. I don't know when I'll get around to doing this though. I'm currently using Mozilla RC3 on Debian Linux and Win32. Debian version is the Debian packaged version 1.0rc3-2. Win32 version is the 5-23-2002 build. I'm also testing with RC2 on Sparc Solaris, although I would rather not debug there. The build instructions for NSS 3.3 are at http://www.mozilla.org/projects/security/pki/nss/buildnss_33.html . RC3 was using NSS 3.4, and today NSS 3.5 should be going into the mozilla 1.0 branch. The NSS 3.5 branch is NSS_3_5_BRANCH , which is what you want to use when pulling from cvs . Specifically when building 3.5 I pull as follows : cvs co mozilla/nsprpub cvs co -r NSS_3_5_BRANCH mozilla/security/coreconf mozilla/security/nss cvs co -r DBM_1_61_RTM mozilla/dbm mozilla/security/dbm Then I build like this : setenv NSPR_AUTOCONF 1 cd mozilla/security/nss gmake nss_build_all As far as your debugging platform, I would recommend you avoid Linux due to the lack of support of threads of the debugger. Both Win32 and Solaris have good debuggers. In any case, the code is the same accross platforms. -- Except for the lack of debugging and the ps thing, [Linux] kernel threads are generally fine right now. And if you're not too fussed about the more fiddly details of POSIX threads, and your application doesn't spend most of its time in thread creation, then LinuxThreads is great too. Linux-Kernel archive
Re: Digitally sign news message
Wan-Teh, Wan-Teh Chang wrote: yz wrote: Hi, I have installed a certificate and I can digitally sign my email. Is it possible in Mozilla to digitally sign messages I send to newsgroups (like in OE6)? There is a request for this feature (http://bugzilla.mozilla.org/show_bug.cgi?id=134949). Wan-Teh Actually it's already possible - see this message as proof :) The trick is to change identiy to a mail account that has a cert associated with it, enable signing, and it works. -- Except for the lack of debugging and the ps thing, [Linux] kernel threads are generally fine right now. And if you're not too fussed about the more fiddly details of POSIX threads, and your application doesn't spend most of its time in thread creation, then LinuxThreads is great too. Linux-Kernel archive smime.p7s Description: S/MIME Cryptographic Signature
Re: FW: Where in a NSPR socket object is the actual file descriptor(fd)?
Cesard, Patrick O. wrote: Hello, If I were to use the PR_FileDesc2NativeHandle function to get to the actual fd of a NSPR socket, and then used this fd in a select or poll call (non NSPR calls) to do multiplexing of I/O, should any consideration be given to whether the NSPR socket is a SSL layered socket or a plain NSPR socket? In other words, Julien Pierre said at one point (this discussion originally started in the mozilla.nspr newsgroup): If it's an NSS socket doing SSL, the fact that there is data on it doesn't necessarily mean that it's application data. You should only read from that socket with NSPR functions, never OS functions What I meant by the above is that the incoming socket data that's been detected might be data for the SSL handshake. Obviously you can't process that with a native recv() or read() call, or you will get garbage. You must use PR_Recv() or PR_Read(). So the better question is then: if my application uses NSS sockets doing SSL, and at some point I get the corresponding native fd as described above, use it in a select call, and the latter detects I/O on the fd, can I safely then call PR_Read on the original NSS socket? You should use PR_Recv() for this case, not PR_Read(). If the incoming data is only handshake data but the peer didn't send any application data, a PR_Read() will block your thread until there is application data actually available from the peer. So you should call PR_Recv() with a timeout of zero instead. This may return no data and seemingly do nothing from your application point of view, but underneath it will in fact consume the SSL handshake data to continue the handshake processing. Similar logic may be needed for other types of (non-SSL) NSPR layering that you can define yourself, which may use headers that are discarded in the layer and never passed to the application. In that case, just like SSL, there is socket data but not necessarily application data. -- Except for the lack of debugging and the ps thing, [Linux] kernel threads are generally fine right now. And if you're not too fussed about the more fiddly details of POSIX threads, and your application doesn't spend most of its time in thread creation, then LinuxThreads is great too. Linux-Kernel archive
Re: Why doesn't SSL SMTP 465 port work with Netscape Messenger?
Michel, Michel Dupagne wrote: Hi! I would like to know why SSL SMTP 465 does not work with Netscape Messenger, at least 4.8 and 7.0. 465 works fine with Outlook Express 4, 5, and 6. I hope you realize that saying SSL SMTP does not work is not nearly enough information to diagnose your problem; That said, the SSL SMTP works fine here. Your problem is most likely of a misconfiguration of your Netscape browsers. Make sure you have the proper ciphers configured that match the ones setup on your SSL SMTP server. Also make sure thqt you have the proper CA certs trusted in the browser.
Re: about NSS
pingzhenyu wrote: How can I buill Nss with VC++,and how can I debug it with VC++ By following the build instructions at http://www.mozilla.org/projects/security/pki/nss/buildnss_33.html .
Re: Better certificate error messages, button for on-demand OCSPvalidation?
Hi, fecund wrote: Using Mozilla 1.2 alpha, and having trouble accessing many sites when OCSP validation is turned on. The typical error is: Error trying to validate certificate from secure3.ingdirect.com using OCSP - response contains a date which is in the future. What I'd like to see in the above error: the site it used to validte said certificate the invalid date eg: Error trying to validate certificate from secure3.ingdirect.com via www.verisign.com using OCSP - response contains a date '99/99/' which is in the future. Anyway, I ask the bank and they say that one of my root CAs has expired or that my clock is wrong. My clock is correct, so I set about trying to debug my certificates. OCSP works fine with https:/secure3.ingdirect.com here, in Mozilla 1.2 alpha. So I think it is indeed your clock. Check your timezone, that is almost always the problem.
Re: SSL Implemenation from NSS
Nimesh Ray wrote: Hello, Can the SSL libraries provided by NSS work on other commercial embedded OSes other than Windows and Unix? Does anyone know if this is done, and if any issues were found related to this? It can be done, but your embedded device will need lots of RAM to run NSS.
Re: create certificate problem
POC wrote: Would it be possible to have the following 2 functions added to the next version of the NSS public API: CERT_CreateCertificate; CERT_CreateValidity; Ian McGreer indicates that the 1st function will make it in NSS 3.5. What about the 2nd one? It too would be most useful in creating a certificate... Also, where on mozilla's Web site can I find a time table for future NSS releases (e.g., NSS 3.5)? -- POC Both of these functions are exported in NSS 3.5 and above. NSS 3.6 was just released, and is already a part of the Mozilla browser. You can pull the source tree from NSS_3_6_BRANCH . As far as the Mozilla web site, http://www.mozilla.org/projects/security/pki/nss/ is the address. It doesn't seem that we have any info about anything past 3.4 . So here is what's missing . NSS 3.5 was a release for the Mozilla browser only. No other products are known to use it. You can pull it from NSS_3_5_BRANCH if interested. NSS 3.6 is a release for a broader range of products, and contains many performance enhancements, in particular with revocation (CRLs). See http://www.mozilla.org/projects/security/pki/nss/nss-3.6/nss-3.6-plan.html . It doesn't appear there is a link to that document frmo anywhere else on Mozilla. http://www.mozilla.org/projects/security/pki/nss/nss-3.6/nss-3.6-plan.html FYI, here is what we are working on now, though the feature list for NSS 3.7 is still subject to change : http://www.mozilla.org/projects/security/pki/nss/nss-3.7/nss-3.7-plan.html
Re: CRL parsing, in C
Patrick, POC wrote: Does mozilla have a API I could use to parse through a CRL? I'm currently using Sun's CertificateFactory and calling the generateCRL() method but I find it very slow when dealing with large CRLs 1 MB...Moreover if I build a list of such CRL objects, my JVM runs out of memory! I'm ready to try a C API.. I looked at the NSS command crlutil, but that tool is geared around the CRL being first imported in the NSS cert DB. -- POC The recently-released NSS 3.6 contains improved CRL decoding. The function you want to look at is called CERT_DecodeDERCRLWithFlags . One of its current limitations is that it can only deal with full CRLs. Delta CRLs, or CRLs containing issuing distribution point extensions, or freshest CRL extensions, currently cannot be decoded with this API. It is likely that this extra functionality will only become available in NSS 4.0. The additional work is not scheduled for the next version of NSS, which is NSS 3.7 . If it is acceptable to you to decode only full CRLs, then the C API should meet your performance need. To give you an idea of how fast the decoding the NSS CRL decoding API has become in NSS 3.6, it is now capable of decoding a 26 MB CRL containing 1.2 million revoked certificate entries in under 8 seconds on a low-end 440 MHz Ultrasparc II machine. This is about 6 times as fast as in previous versions of NSS. It also needs about 1/4 as much RAM as before to do the decoding - which is still an additional 35 MB of memory, on top of the 26 MB DER source CRL. Both improvements are the result of a new ASN.1 DER decoder I wrote for NSS 3.6, called the QuickDER decoder (see SEC_QuickDERDecodeItem if you are interested). Documentation on that new decoder - as well as on the old, less efficient SEC_ASN1DecodeItem - will be written in upcoming months. But you don't need to use the ASN.1/DER decoder directly to decode a CRL. The cert.h header file should contain sufficient documentation on how to call CERT_DecodeDERCRLWithFlags .
Re: CRL parsing, in C
microseconds on the 2.2 GHz Xeon CPU system I'm using to type this. To be able to take advantage of the performance improvements from the CRL cache, you need to use the NSS certificate verification functions mentioned above, and the CRL must be present in a PKCS#11 token. It should be noted that the official PKCS#11 specification doesn't currently include CRLs. We (Netscape) defined extensions to support this. Only the NSS certificate database (softoken) and some other internal Netscape proprietary PKCS#11 modules currently support these PKCS#11 CRL extensions. So at this time, your only option is to import your CRL to the database. The crlutil tool will allow you to do that. You can then start your NSS application against that database containing the CRL, and simply call the certificate verification functions. The CRL check will be automatically performed. The first time you verify a certificate from your CA, NSS will transparently read the CRL from the database, decode it, and put it in the cache along with the hash table. So your first verification will take a long time. Subsequent certificate verifications however will be very short. The 50 microseconds revocation check time is actually negligible compared to the rest of the certificate verification. With a cerificate containing a 1024 bit RSA key, the signature verification will take over 500 microseconds. With a 2048 bit key it will be much longer. So basically the CRL check will be invisible overhead after your first verification. Note that in versions of NSS before 3.6 that didn't have the CRL cache, the CRL was pulled from the tokens, decoded, and freed, for every certificate verification. Needless to say, the performance with that method was not impressive and this is why the CRL cache was added. -- POC -Original Message- From: Julien Pierre [mailto:jpierre;com.netscape.netscape.com] Sent: Tuesday, October 29, 2002 5:51 PM To: [EMAIL PROTECTED] Subject: Re: CRL parsing, in C Patrick, POC wrote: Does mozilla have a API I could use to parse through a CRL? I'm currently using Sun's CertificateFactory and calling the generateCRL() method but I find it very slow when dealing with large CRLs 1 MB...Moreover if I build a list of such CRL objects, my JVM runs out of memory! I'm ready to try a C API.. I looked at the NSS command crlutil, but that tool is geared around the CRL being first imported in the NSS cert DB. -- POC The recently-released NSS 3.6 contains improved CRL decoding. The function you want to look at is called CERT_DecodeDERCRLWithFlags . One of its current limitations is that it can only deal with full CRLs. Delta CRLs, or CRLs containing issuing distribution point extensions, or freshest CRL extensions, currently cannot be decoded with this API. It is likely that this extra functionality will only become available in NSS 4.0. The additional work is not scheduled for the next version of NSS, which is NSS 3.7 . If it is acceptable to you to decode only full CRLs, then the C API should meet your performance need. To give you an idea of how fast the decoding the NSS CRL decoding API has become in NSS 3.6, it is now capable of decoding a 26 MB CRL containing 1.2 million revoked certificate entries in under 8 seconds on a low-end 440 MHz Ultrasparc II machine. This is about 6 times as fast as in previous versions of NSS. It also needs about 1/4 as much RAM as before to do the decoding - which is still an additional 35 MB of memory, on top of the 26 MB DER source CRL. Both improvements are the result of a new ASN.1 DER decoder I wrote for NSS 3.6, called the QuickDER decoder (see SEC_QuickDERDecodeItem if you are interested). Documentation on that new decoder - as well as on the old, less efficient SEC_ASN1DecodeItem - will be written in upcoming months. But you don't need to use the ASN.1/DER decoder directly to decode a CRL. The cert.h header file should contain sufficient documentation on how to call CERT_DecodeDERCRLWithFlags .
Re: About CRL Utility (crlutil)
Patrick, POC wrote: About that -u option: does NSS use the URL at all? (like automatically fetching a fresh CRL once the CRL expires), or is it just simply stored in the cert db for the crlutil user to retrieve at a later date (using cerlutil -L)? I don't think NSS uses it other than providing a way to save / retrieve the value. I believe PSM (a component of the Mozilla / Netscape browsers) uses it as the download location if you enable automatic refresh of CRLs.
Re: openssl key/cert - NS key/cert db
liug wrote: 4) now try to import it (I already have key3.db and cert7.db created). pk12util -i test2.p12 -d . it gives: pk12util: PKCS12 decode validate bags failed: The user pressed cancel. any ideas? thanks! frank Did you specify a password on your p12 file when you created it ? Does your database have a password set ? In either of these cases, you must pass parameters to pk12util on the command-line. I don't believe it will prompt you for the password. The parameters are -K slotpw (where slotpw is your database password) and -W p12pw (password of your p12 file). An easier way is to use PSM in Mozilla and click Import, and it will prompt you for any passwords you need to enter.
Re: openssl key/cert - NS key/cert db
liug wrote: Nelson B. Bolyard [EMAIL PROTECTED] wrote: liug wrote: How can I use the NSS tools to convert a openssl generated key pem file to netscape key3.db ? I believe there is some OpenSSL program that will create a .p12 file (a.k.a PFX file) from your key/cert. Mozilla can import the .p12 file. quick question: does iplanet webserver6 support 1024bit key? Yes. By default it will use 1024 bits in fact. my openssl generated key is 1024bit, could it be a problem that I can't import into iplanet? No, that can't be the problem. btw, I have an apache webserver with ssl key/cert, and I need to convert to iplanet6. You could open a bug against NSS and send us the P12 file by e-mail if you are comfortable with doing that, so that we could see what the problem is. Otherwise you will have to create a new key cert.
Re: openssl key/cert - NS key/cert db
Nelson B. Bolyard wrote: .p12 files contain the nickname for the certs. When mozilla imports a cert from a .p12 file, it uses the nickname found in the .p12 file. If I'm not mistaken, iPlanet web server requires that the server's cert have a particular nickname. It's possible that this was a requirement of the 5.x server but not the 6.x server. Julien, can you tell us what nickname the server cert should have? The default name used by all versions of NES is Server-Cert . It is however configurable. In NES / iWS 4.x versions, you set the nickname of the cert in magnus.conf using the CERTDefaultNickname directive. This has to be set manually - there is no admin UI support for it. In 6.x , the nickname of the cert is configurable through the UI. It is stored in server.xml within the SSLPARAMS structure.
Re: How do I set the default Certificate?
Tom, tom glaab wrote: All my certs are current and issued by the same CA. The subject is different, though not by much (basically a firstname.lastname.serial). The reason I have multiple certs from the same CA is political, and the older, primary cert has more functionality but I have to keep the new one for a server that will be stood up soon. So we're back to the problem that I have multiple valid certs, but I prefer to use something other than Mozilla's default selection. Since your certs have distinct subjects (it doesn't matter how little the difference is), they will have different nicknames. You can choose which cert to use. Select ask every time in the manner indicated in the previous message. You will then be prompted with a dialog which will contain the list of valid certs, and you will be able to pick the one you want. It is true that there is no way to override the automatic selection with your own cert. However, the automatic selection is a dynamic process, as I mentioned previously. It is dependent upon the acceptable CA certs of particular servers. If you have multiple certs from different issuers (as for example, I do), then a default cert is meaningless. To take a concrete example : I have a cert from Thawte and a corporate cert. Which one do I set as default ? Corporate sites will require the corporate cert, and other certs from Thawte may require the Thawte cert. The corporate cert is never acceptable to the Thawte servers, and vice versa. A default only makes sense when there is ambiguity, ie. you have two certs from the same issuer. There would have to be one default cert per issuer, rather than a global setting for the default cert. Or perhaps you would set a priority list of acceptable certs, that would be combined with the acceptable CAs when you connect to an SSL server. In either case, this would make a very complex and confusing UI. In truth, most people do not have more than one valid cert per issuer with a different subject, much less more than one valid cert for more than one issuer. Therefore, in my opinion, the complexity of that UI would outweigh its benefits. The ask every time setting already allows you to do what you need, at the cost of an extra click at connection time as you get prompted. Another suggestion : if you never use the other (non-default) certificate, you may as well delete it from your cert database, and Mozilla will then automatically make the right choice of certificate since there will be no ambiguity.
Re: How do I set the default Certificate?
Hi, tom glaab wrote: Julien Pierre [EMAIL PROTECTED] wrote In truth, most people do not have more than one valid cert per issuer with a different subject, much less more than one valid cert for more than one issuer. I'm in the minority then, and it is annoying. I've had a corporate cert for years, and it includes an email cert. Now a mandate has come down for everybody to get an identity-only cert from the same corporate CA, even if you already have one. Normally, this is acomplished not by changing the subject of the certificate, but by changing the keyusage. Changing the subject does not make sense if the two certs belong to the same person and are from the same issuer. This tells me your PKI is not implemented correctly. For example, I have two corporate certs, one which is for encryption and another for signing. The subject of both certificates is identical. The signing certificate is used for identification purposes. You can see them both in the signature of this message. I do find it annoying. While it's probably rare to find a person with multiple certs from the same CA I can see it happening more often... a single user may have his normal identity cert but also have a privileged or administrative cert. This probably shows more about the corporation's ignorance of PKI, but that's another story. Well, there you go ... smime.p7s Description: S/MIME Cryptographic Signature
Re: Aladdin eToken and Mozilla
Hi, Remo Inverardi wrote: Caption: Alert, Message: localhost has received an incorrect or unexpected message. Error Code: -12227 This means SEC_ERROR_REVOKED_KEY . Are you using any means of certificate or key revocation ? Eg. OCSP, CRLs, or CKLs ? Is PKCS#11 support in Mozilla actually supossed to work? Is there any possiblity for turning on debugging / trace functionality of the Mozilla PKCS#11 code? Yes, it is supposed to work. You can turn on debugging, but it will make sense only if you know the PKCS#11 interface. See http://bugzilla.mozilla.org/attachment.cgi?id=86663action=view .
Re: Using Softoken as standalone pkcs#11 module?
Christoph Brueckner wrote: hi, NSS is using the softoken as internal pkcs#11 module. Is it possible to turn the softoken into a real standalone pkcs#11 module, which can be used by other applications beside Netscape/Mozilla? What is this cryptoki framework (ckfw) all about? Is it possible to integrate the softoken into the ckfw, or does the softoken largly depend on NSPR and other netscape stuff? Does someone actually integrated the softoken into the ckfw to build a standalone pkcs#11 softoken? Is there any documentation for the softoken and the ckfw. Unfortunatly i didnt find any :-( Its hard to understand ckfw and softoken without any diagramms or documentations. best regards Christoph Brueckner At this time softoken is still tied to NSS. It requires an initialization string to be passed to C_Initialize. If you can make your other applicaitons pass that string, you might be able to use it. You may also have to use NSPR in your application for certain things like locking, as softoken uses NSPR. CKFW is a cryptoki framework. Its purpose is to provide a template for a PKCS#11 module implementation. It contains sample code for all PKCS#11 functions. It speeds up writing a PKCS#11 module by making it possible to write only a little bit of code for the PKCS#11 functions that are of interest to your module, while using the sample implementations for the rest. CKFW is used as the basis for the root certificate module, for example. It is also used in other products that ship their own PKCS#11 modules, such as Netscape Enterprise Server 6.1. softoken was written separately and isn't based on ckfw. Since it implements nearly all functions in the specification, making softoken use CKFW wouldn't make sense.
Re: Include corporate CA certs in Mozilla distribution
Ray, Ray Charbonneau wrote: We run our own Netscape CA, and have included the appropriate certs in our Netscape 4.7x installation package. These certificates appear in the Mozilla Certificate Manager when I upgrade a profile from Netscape to Mozilla. How can I include these certs in new profiles created with Mozilla? Where is the default cert#.db stored, and how can I update (or replace) it? There is no default cert DB. The certs are stored in a PKCS#11 module called the built-in module. See mozilla/security/nss/lib/ckfw/builtins . The library makes the certs available, as well as the default trust. You could distribute your certs by modifying that library, or creating your own copy containing only your corporate cert and its trust. It is probably simpler to chain your corporate CA to a known root, however.
Re: crypto toolkit
boutteau wrote: I am loocking for a tool kit to do file signature: 1) select a file 2) select a certificate 3) sign the selected file with the certificate 4) create .zip with 2 files : - selected_file.ext - selected_file.ext.sig Second tool is to verify than a file and signature are matching (with OCSP to verify the revocation of the certificate). Result : Y or N with any information on the certificate which was used to sign. Third tool : same than one but for cripting Forth tool : a tool to decript if I have the right key to do it Can we imagine those tools in Mozilla for any future and when? Please take a look at NSS athttp://www.mozilla.org/projects/security/pki/nss/ . It is the open-source security library that is at the heart of the mozilla browser. It contains many tools that will do what you need. cmsutil and signtool are the tools you want to look at for signing and encrypting.
Re: Certificate Selection
Henrik, Henrik Gemal wrote: How does Mozilla select certificates to show to a webserver when the server asks for a certificate? The web server firstsends Mozilla a list of valid CA certificates from which it will accept client cert. Mozilla then looks through the available client certs. The most common case is there is zero or one match, so the automatic choice is easy. If there is more than one, I believe Mozilla will pick the most recently issued certificate. You can however force Mozilla to prompt you by setting Edit/Preferences/Privacy Security/Certificate/Ask every time . If a spammer set up a cert login site I would automaticly show me the cert? Yes, but only if they first knew who issued your certificate, as the spammer's SSL web server would need to present the correct issuer CA certificate for this to work. Also, note that presenting your certificate to a spammer does not accomplish anything more than authenticating you as the owner of the certificate. The spammer knows who you are at that point based on the certificate, however he cannot replay the authentication, because he doesn't have the private key.
Re: Certificate Selection
Stephen Henson wrote: Although a server sending an empty list is strictly speaking illegal in SSL/TLS some implementations will tolerate it and interpret it as any CA. No idea if Mozilla does though... NSS enforces the SSL/TLS specs and will not tolerate an empty CA cert list from the server.
Re: CERT_DecodeDERCrl
POC wrote: Hello, I have a NSS server app that decodes CRLs all day long (a poor man's OCSP responder). However this app has a memory leak. I'm using the CERT_DecodeDERCrl() function. This function returns a pointer to a CERTSignedCrl object (call it signedCRL). What is the right way to release the memory when done decoding? I'm currently using SEC_DestroyCrl(signedCrl). You are calling the right function to free the CRL. Are you sure the leak is related to CERT_DecodeDERCrl ? Also, which version of NSS are you using ?
Re: CERT_DestroyCertificate
Patrick, POC wrote: Hello, I create a CERTCertificate object using CERT_FindCertByName() and then destroy it using CERT_DestroyCertificate(). However the cert.h file states this about the function: ** NOTE: certificate's are reference counted. This call decrements the ** reference count, and if the result is zero, then the object is destroyed ** and optionally freed. What if I definitely want to free the CERTCertificate object memory? Wouldn't this function cause a memory leak if I repeatedly call CERT_FindCertByName/DestroyCertificate and the memory is *optionally freed*? -- POC As long as you call CERT_DestroyCertificate the same number of times as CERT_FindCertByName (or any other function that returns a CERTCertificate), there will not be a memory leak. You may not be able to force the memory to be freed in some circumstances. For instance, in a multithreaded program, multiple threads may be manipulating that same certificate, and hold a reference to it. The CERTCertificate pointer in all those threads will be the same. If one thread definitely freed the CERTCertificate memory, then the pointer would become invalid, and the other threads that still have a reference to it would crash when trying to dereference it. As long as you call destroy once per find function, your program will function as expected. If your program isn't multithreaded, then there is a good chance that the destroy function will indeed free the memory. But even that isn't guaranteed. You could have other objects referencing the same certificate in the same thread, for example a cert list, a cert chain, etc. The memory only gets freed when there the last user of the CERTCertificate calls the destroy function.
Re: crypto.signText() and Form-Signing
Luis Fernando Pardo wrote: Are you sure Netscape 6.2 is implemented over Mozilla 1.3b?. In www.mozilla.org I have read that Netscape 7.02 is based on mozilla 1.0.2. If it is true, my component will not work with netscape. Netscape 7.02 is based on Mozilla 1.0.2 . Netscape 6.2 is based on some pre-1.0 version of Mozilla, I believe 0.9.4 .
Re: NSS Apache Module
Shawn, Shawn Carnell wrote: Has anyone else tried to build an apache module that uses NSS? I have. It's not going so well. For what purpose are you trying to use NSS ? Are you trying to implement the SSL front-end of Apache with NSS (ie. an alternative to the old mod_ssl) ? And what version of Apache are you writing the module to ? Is it the non-threaded 1.x or the threaded 2.0x ? Though i can get the module to load, its logging behavior is suspect (only the timestamp and other prefix information are output; apache seems oblivious to the value of arguments to ap_log_error). I think this bespeaks of more sinister problems afoot. NSS requires about a dozen other shared objects. I think i'm now seeing apache dump core based on a misplaced shared object but i'm having trouble determining the exact cause. I've spent lots of time looking at truss output. I haven't had much luck running apache in gdb (http://httpd.apache.org/dev/debugging.html); if you've done done this before, i'd really appreciate a moment of your time just to get a few pointers. Oh, i'm developing on Solaris. Traditionally, on Solaris, we have been using the Sun compiler to build NSS. While NSS may build with GCC, we never did that inside Netscape. If you have access to the Sun C compiler, it would be a good idea to compile NSS with it. The dbx debugger is also better than gdb, if you have access to it. I'm not familiar with the logging in Apache. I have written NSAPI modules for the Netscape server products which used NSS, and this was not a problem. One thing that you may be running into is symbol conflict. Use the nm command on all the .so files from apache and NSS and see if there are any conflicting symbols. If so, they will need to be renamed.
Re: IIS with client certificate incompatible with Mozilla ?
Richie, Richie B. wrote: I have a customer who is running IIS 5.0. We need to contact a page on that server that is protected with SSL and requires client certificates. I have imported the client certificate in Mozilla 1.4 on Linux. When I access the page, the server responds: HTTP 403.7 - Forbidden: Client certificate required The User Identification Request popup is never shown. However, when I connect with IE6, a similar popup is shown, and I can access the page. Also, using openssl s_client -cert client.pem works fine and shows the page. I have tried to debug this, but the problem is that the server only requests the client certificate after the browsers sends the GET statement. So, the first (readable) handshake is without client certificates. The renegotiation that happens after the GET is encrypted and I cannot see the problem. I am guessing this is an IIS issue, but I cannot prove it. Has anyone else seen this? Any ideas? First, make sure that you set your client to always prompt you to select the certificate. I don't know how you specifically configure this in IIS, however : When doing client auth, the SSL protocol requires the server to send the subject name(s) of the trusted certificate authority(ies) to the client. You need to configure the certificates you trust for client auth in IIS. Some misconfigured servers may not send over the subject list. If that's the case, Mozilla may have a hard time choosing a client certificate. If you trust the CAs it will most likely solve your problem. It may also be that your client certificate was incorrectly imported in Mozilla, or its issuer doesn't match the subject sent over by IIS. If none of this applies, there may be a Mozilla/PSM/NSS bug, but in order to solve it we most likely will have to be able to access your server.
Re: cert8.db and CRLs
Patrick, POC wrote: I have to large CRLs, one is ~2.3MB the other ~2.7MB that I have successfully imported in my cert8.db. I actually see the 2 files created in cert8.dir. Check that crlutil -d . -L can decode and list the CRLs properly. However now my NSS server app core dumps... Without the stack trace and the version of NSS you are using, we can't help you. It does NOT dump when the CRLs are DELETED from the cert db...The puzzling thing is that NSS should not be even touching these CRLs since my client is connecting anonymously... NSS may use the CRLs when verifying any certificate from the CRL issuer. Even though your clients are not connecting with client auth, it is possible that your server is doing other PKI operations with NSS that end up using the CRL.
Re: Firebird/Thunderbird and PKCS#11
Jean-Marc, Jean-Marc Desperrier wrote: Julien Pierre wrote: [NSS DB access not multi-process safe] Solving this problem involves using a new database format. The NSS team researched the issue of licensing other database code that didn't suffer from the single-process limitation, but none was found that would satisfy all licensing requirements - NPL/GPL/MPL. The only satisfactory databases we found were commercial. Unfortunately we didn't have the resources to write a brand new database, hence the situation we have today. I'm surprised this problem has no solution. Well most database solutions seems to be available only under the GPL, but a special agreement could probably be negotiated. We have a solution that works for our commercial products, which cost AOL money. But we can't open source that solution. We tried to negotiate with the database vendor we chose, but it wasn't possible, because it would mean that their source code would end up in mozilla and the MPL/NPL allow commercial products to be created from that source code. But the best solution would probably be a separate process that will handle all the crypto/NSS requests for the running aplications. It seems clear this is the most workable solution. If needed, it could be done with a proxy without changing anything in the current interface. Was not the PSM intended to work that way initially ? Maybe it was, that predates my time, but it doesn't work this way today. Having the crypto done totally out of process has security issues : sending sensitive data to encrypt over IPC is not a good idea, and it is also very inefficient. The real solution is to hook up NSS to a multiprocess-safe database. That way only the database I/O goes through the IPC, not the crypto operations. There is a provision to do that in the open source code. The problem is that no database could satisfy the requirements to be included in mozilla.org source code.
Re: Update stored passwords
Robert, Robert wrote: Hi! I'm currently developing a password manager application for the Windows platform which monitors the Mozilla password file (12345678.s) and stores the password entries on a smart card. Ideally, the passwords should be written to Mozilla's password file when the card is inserted and deleted when the card is removed. However, there is a major problem: Mozilla only reads the password file when the browser (or the QuickLaunch tool) is first started, so modifying the file while Mozilla is running is pointless. Is there any way (Window message, etc.) to tell Mozilla that the password file has been changed so that it can update its internal list? If not, this would be a major improvement, which shouldn't be very difficult to implement :) This might be a different application from what you want, however it is probably simpler to implement : You could store the symmetric encryption key used to encrypt your password on your smartcard, instead of storing it in the security device. Therefore, you would only be able to access the passwords when the smartcard is inserted. Assuming you already have a PKCS#11 driver for your smartcard, the code change to do that in Mozilla should only be a minor change - look at the SDR functions. You would just need additional UI to select which security device to use for the password key. However I realize this does not offer the same benefits as storing the passwords themselves on the smartcard. With the approach described above you can't go from one machine to another with your smartcard and expect to transfer your passwords. If you always keep the password file encrypted, that problem might be solved by putting it on the network rather than on the local disk.
Re: NSS PKCS#11 Module
LiuPeng, liupeng wrote: Thanks for Julien Pierre answer! I want to do a low-level RSA encrypt for my proprietary application and I use smart card (gd spk) as my hardware device(Both the public key and the private key stored in smartcard). Firstable, to do an RSA encrypt using a public key, you don't really need to actually perform the operation on the smartcard. If you imported the public key into your hardware token, and use the resulting public key handle of that token key for the operations, NSS will first try to perform the operations on the smartcard's PKCS#11 module. If that fails, it will then fallback to doing it in software using softokn. Before I use nss for my proprietary application,I use pkcs11 hardware module directly. I want to use public key to encrypt some my proprietary data,and use pkcs1.5 padding mode(CKM_RSA_PKCS).Later I use the corresponding private key to decrypt it.(Maybe I also use the private key to sign some data and use publickey to verify the signature.) But it seems function PK11_PubEncryptRaw use CKM_X509 mode,and I don't know the detail implementation of pkcs1.5 padding mode.Does nss support any function to do this? Does the function PK11_CipherOp seems can do this?If it can do,how do I generate a PK11Context pass to function. PK11_CipherOp only works for bulk (symmetric) ciphers. You can't use it for RSA public key ops . After much questioning of other team members, we have come to the conclusion that there is no function today in NSS that directly does what you want. We only use RSA encryption and decryption to wrap and unwrap symmetric keys (such as for SSL and S/MIME), but not for actual application data, and therefore we didn't provide a function to encrypt and decrypt data using RSA. If you are using RSA to encrypt a symmetric key, then you can use the function called PK11_PubWrapSymKey . Pass it CKM_RSA_PKCS, the handle to your public key on your token, the handle to a symmetric key, and a SECItem* which will contain the wrapped (encrypted) key. If what you are encrypting with RSA is not a symmetric key, what you can do is create a dummy symmetric key from the data you want to encrypt with RSA. Use PK11_ImportSymKey to import your symkey (actually your data to encrypt) . The key data will be in a SECItem structure which simply contains a void* and a length. I think you can use a CK_MECHANISM_TYPE of CKM_GENERIC_SECRET_KEY_GEN and a PK11Origin try PK11_OriginGenerated . You can destroy the fake symmetric key using PK11_FreeSymKey after you are doing encrypting. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Can't get a simple SSL server to work using NSS
Julien Pierre wrote: Khaled Hassounah wrote: Try adding a call to NSS_SetDomesticPolicy() . This will enable all the domestic ciphers. Setting followup to netscape.public.mozilla.crypto . ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Why a SSL server can't get certificate of client?
Hi, yangbingyu wrote: I'm trying to use a SSL server with NSS,but I get a error that is -12199(No certificate authority is trusted for SSL client authentication), The error is quite explicit. In the server database, you need to add the CA certificates that you trust for client authentication, and mark them trusted. You can perform both operations using certutil. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: CRL Management
Scott, Scott Rea wrote: OK, we require them, how do we get them added to the list of future fuctionality and what is the usual timeframe for something like this to make it from design to release? The first step to get this into Mozilla would be to file a bug in bugzilla, of type enhancement request, on component PSM (Personal Security Manager). The next step would be to find a programmer to implement it. As far as I am aware, there is no one officially working on PSM at this time. So you may want to contribute your own time or find a programmer willing to add the functionality. At the core it is not very difficult with NSS, I suspect the user interface work is the most complicated part. When importing certificates, it would appear that certs stored in binary do not work, only pem or base64 encoded certs seem to be able to be imported. Is this correct? Cert in binary should work. Make sure you receive no extra data at the end. As Jean-Marc said, binary certs should work. Try to use the extension .der for the ones that don't work and see if that fixes the problem. Further investigation shows that binary certs do work (some of the time). I can take a binary (or base64) encoded cert and import into the Other store, sometimes it just does not work and I get a silent failure i.e. no notice of fail, cert just does not show up (perhaps this could be a refresh issue) But if I just try the cert again, next time around it seems to work - this appears to be a bug. The UI part for importing certs in Mozilla certainly seems weak. You should file a bug for it (again against PSM). ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: 128 bit encryption in FRANCE
Adrian M wrote: Hi... Does someone know if they allow now 128 bit encryption in France ? ( it used to be that only 56 bit encryption can be used in France ). Is mozilla.org concerned about this ( maybe offering a special browser that uses only 56 bit encryption or something like that ). Thanks. The legislation in France changed several years ago and the use of 128 bit keys is currently legal in France. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: LDAP CRLs
Scott, Scott Rea wrote: This is exactly my issue - thanks for putting it so succinctly Nelson!! You should be able to import the CRL into Mozilla using an LDAP URL, such as ldap://strange:1389/uid=ca,dc=netscape,dc=com?certificaterevocationlist;binary . Of course the URL must match your directory. Do you get any error message when you try this method ? ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: LDAP CRLs
Scott, Scott Rea wrote: I am doing this on a Windows 2000 box and an LDAP URL opens the Windows Address Book [not very helpful] whether I enter the URL in IE or Mozilla. How can I get Mozilla to do the same as it does for *.crl files that are entered into the address bar? Woops. Looks like unfortunately this is another RFE that you need to file ... The underlying security library (NSS) is capable of processing the CRLs from any source, and in fact we support fetching CRLs from LDAP in products other than the Mozilla browser (Netscape server products), but it appears the LDAP support for CRLs just wasn't put into Mozilla. Your best bet in the meantime when using Mozilla would be to fetch the CRL over HTTP. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: signtool 1.3
Nicholas Wright wrote: Yes - but signtool doesn't recognize cert8.db. How do you sign things now? If you get a full distribution of NSS 3.8, or build it yourself, the signtool will work with cert8.db . ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Missing nss libraries in Darwin tarball
Keith wrote: Hi, I am attempting to build an application that requires the NSS libraries. When I downloaded the current tarball (version 3.8) for Darwin (OS X), the lib directory is empty. This is not the case in tarballs for other OSes. Hmm, indeed, that's quite odd. We will look into this. Where can I find the libraries already compiled for Darwin? If none are available, will they be built during compiling of the source? Yes, they will be built if you compile from source. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Certificate Chains, PKCS12 and Mozilla
Hi, [EMAIL PROTECTED] wrote: I have a PKI with 3 levels: 1. A root self-signed certificate at the first level 2. Sub certification authorities certified by the first one at second level 3. User certificates certified by second level authorities at third level. That is a fairly typical PKI. All you need to do for the CA to be recognized is to get a copy of the root CA certificate in DER format and trust it. Send it around with the extension .DER . When a mozilla user clicks on it, he will be prompted to trust the certificate. The exact window will say : Downloading certificate. You have been asked to trust a new Certificate Authority (CA). Do you want to trust your CA name here for the following purposes ? X Trust this CA to identify web sites. X Trust this CA to identify email users. X Trust this CA to identify software developers. You just need to trust it to identify email users. To implement this scheme I create the PKCS12 files for users adding two certificate bags (the first one is the certificate corresponding to the sub-authority certificate and the last one the user certificate). The PKCS#12 format is designed to transport certs and keys. However, it does not transport trust. Trust is up to the user. It sounds like your users already have the root certificate, but it's not trusted. In that case, go to the Manage certificates window (under Edit/Preferences/Privacy security/Certificates/Manage certificates). Go to the Authorities tab. Click on your cert once. Then click the Edit button at the button. Check the check box for This certificate can identify mail users. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: NSS ignoring next update on CRL check
Jean-Marc, Jean-Marc Desperrier wrote: All in one, I don't think it's a good pratice at all not to include this verification inside the crl check function. There is no client that should have a need to continue to trust an outdated crl. It's standard practice that if the only available crl is outdated, then all certificate check will fail. This how Apache works, IIS works, etc. First, I think you need to distinguish between client and server applications. They clearly don't have the same security requirements. Netscape Enterprise Server (NES), which is a server, and also uses NSS, has much more stringent requirements for CRL freshness, and probably more configuration options in that area than both Apache and IIS - I must admit I have not looked at them, but CRL support for NES was something I spent about 4 months on and I can tell you it is quite extensive. The same requirements did not apply to the client, and in particular to PSM, so the support for CRLs in PSM is much lighter. Apparently this change has been made out of concern that the client may not have enough time to download the new crl before making the check. But the standard way to handle this case in PKI deployment is for the CA to emit a new CRL before the next update date, allowing ample time for the client to download the new crl before the actual next update. So that the next update is not actually the time at which a new crl will exist, but the time at which it becomes inappropriate to continue to trust the CRL. I have never seen an explicit stated requirement to interpret nextUpdate as a CRL trust mechanism in the way you state, neither for the client or the server. Trust is generally something that is left to the implementors, both for certificates and for CRLs. nextUpdate is in fact an optional field in a CRL, though current profiles tend to require it. While the logic you describe in Apache does not seem unreasonable, it isn't the only one. In many situations, eg. if your client (or even server) is in a submarine, with no available connection to the outside world to download a newer CRL, it may be acceptable to use the latest CRL available, even if the nextUpdate has passed, than to fail altogether. In NES, the chosen approach is different from Apache as far as CRL trust. In NES, CRLs are considered trusted if their thisUpdate field is within a certain time interval of the current date. This is called a maximum age. nextUpdate is not considered. The web server can be configured to shut down if the latest CRL exceeds that age, so that nobody can login to the server as proper authentication mechanisms have become unavailable. As you can see this is pretty stringent, and you wouldn't want your client to shut down similarly in this case. It is true that there is no way for NSS to just make the certificate verification for that CRL issuer fail if nextUpdate is considered too old. Even in NES, the age check is only performed at the time the CRL is downloaded, not at the time of each certificate verification. It wouldn't be too hard to implement such logic now that there is a CRL cache however. There are plenty of cases where all verifications for the issuer will fail. In fact, Mozilla crl manager conforms exactly to this logic by enabling to download a new crl n days before next update, or at a regular interval different from next update. If Mozilla downloads a CRL before nextupdate, it cannot be guaranteed to get a new CRL than it already has, since the CA does not guarantee it will generate a new one before nextUpdate. And even then, there is a bit of leeway. Many CAs (CMS included) will start the new CRL generation at nextUpdate, but in some cases it may take a long time to generate, so that the new CRL won't really become available until nextupdate+some delta ... We don't want the clients to fail in that case either. Even if a user uses only manual update, and not automatic download, it should be warned that the crl is outdated by the failure of cert check, so that he know he must update the CRL. Currently there is no NSS error that indicates that the CRL is outdated and needs to be updated. It is very hard to get something meaningful back to the user, even knowledgeable users like us, let alone average users. At this time, there is only a Revoked certificate error code. It is the same code that will be returned whether that failure is caused by an OCSP check or a CRL check. Moreover, certificates are verified on a chain basis, so the application would have to identify which CRL in the chain is outdated, since you can have CRL not only for the immediate certificate issuer but at any level. This is a lot of work, which I have to admit NSS does not make very easy for applications, and which the Mozilla browser definitely does not perform. If not, I hope at least some change will be brought rapidly to PSM to reimplement the checking of crl_update. I think you should file
Re: PSM and crl distribution point
Jean-Marc, Jean-Marc Desperrier wrote: Is there a way to get PSM to make any use of the crl distribution point (crldp) extension ? How is it handled within NSS ? (I could check the source/doc. I will if nobody feels inclined to respond) Or you could type distribution point in bugzilla query before posting :-). This is not currently supported in NSS. See bugzilla 133191 . At this time, the only CRL format supported by NSS is full CRLs. delta CRLs support should be fairly easy to add given the current design of the CRL cache, but it has not been a priority. See bugzilla 148214 . I have done some work on distribution point as well, and this is reflected in the CRL cache, but it is not complete either and is even lower priority than delta CRLs. Look for the word XCRL and #if 0 in mozilla/security/nss/lib/certdb/certi.h . ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: NSS ignoring next update on CRL check
Jean-Marc, Jean-Marc Desperrier wrote: In many situations, eg. if your client (or even server) is in a submarine, with no available connection to the outside world to download a newer CRL, it may be acceptable to use the latest CRL available, even if the nextUpdate has passed, than to fail altogether. If you're in a submarine with no connection, you don't receive new information, so you don't have a need to verify the validity of new content. Not new content, but you may be still be validating some older content, such as e-mails you received prior to disconnection. When using the logic you suggested from Apache, this verification would fail because the CRL would be considered outdated. Except if you recheck the validity of content you already own everytime you access it. Mozilla definitely does that with e-mails. And in a way, that's a good thing, because CRLs can contain information that is retroactively added. Eg. somebody got their key/cert compromised on 11/1, but did not become aware of it until 11/4 . The cert can be retroactively added to the CRL on 11/5. If users received forged e-mails signed with the forged cert between 11/1 and 11/4, and fetch the new CRLs, those e-mails will no longer verify. Since certs cannot be unrevoked (the only exception is for a cert going from on hold status), it might be a good thing for Mozilla to mark content as invalid once the verification fails due to revocation. This way the verification would not have to be performed again. This would be good so that 2 years from now, when the cert has expired and is no longer on the CRL, the e-mail does not suddenly verify. Unfortunately the NSS cert db only supports one CRL per issuer at the moment. I opened a bug on that but can't recall the number right now. But then you are getting away from a situation where the real-time paradigm applies (in this case I don't need to worry about time when validating content, because everything is done in a short enough interval that all revocation information is still available and valid). So your check would need to include the date to check the validity at, and if this date is before next update or before the revocation date of the certificate, the content is valid. OCSP is more appropriate to the real-time scenario than CRLs are. CRLs can get large, and for that reason they are generally used in servers rather than in clients. I believe that's one of the reason why they weren't given high priority in PSM, back when someone was still working on that component. So a properly configured NES is secure, even if next update is not considered. But other users of NSS should beware of the way they use the function. Yes. [...] Even in NES, the age check is only performed at the time the CRL is downloaded, not at the time of each certificate verification. This seems to contradict what you say earlier about NES shutting down if the latest CRL exceed the maximum age. If this check really done only when downloading the crl ? Yes, it is done when downloading only, but the server can be set to periodically download CRLs on a very frequent basis, in a background thread, so that it would really shut down in this case if it didn't get an up to date CRL. Maybe a larger sample of usual practice would be useful but notice that a crl issuer like Verisign emits everyday crl that have a next update set to 7 days later. So you have to miss 6 daily updates, before being in a blocking situation. Yet if you did not enable the automatic update, it's almost a given that you will run into the blocking situation, unless you remember to manually update it every day. Microsoft CAPI implements this by starting a download for all CRL that are found outdated in the chain verification. Independant CRL download by a CRL manager as done in PSM is probably a better solution, but I think that failure to get updated CRL should be a failure case, not transparent. NSS itself never initiates a download of a CRL. We try never to initiate any ouside connection because we want our function calls to return ASAP, since in many cases applicatinos use NSS functions in blocking mode. NSS searches for CRLs for each issuer in all available PKCS#11 modules. This itself is a Netscape extension, since the official PKCS#11 spec does not specify CRL object storage. Typically, the only PKCS#11 module available that has CRL is the NSS softoken. CRLs are stored in cert8.db, or in the cert8.dir subdirectory if they exceed the size of a dbm record (4kB). So you can write code that will download CRLs and import them to the cert DB - which is what Mozilla / PSM do. Or you can write your own PKCS#11 module to make CRLs available to NSS. This is what I did for NES. That PKCS#11 module does the download in memory only. Theoritically it could be integrated into any NSS product, but it is not open-source and only part of NES at this time. If we consider emitting a new CRL only at next update to
Re: PSM and crl distribution point
Jean-Marc, Jean-Marc Desperrier wrote: This is not currently supported in NSS. See bugzilla 133191 . At this time, the only CRL format supported by NSS is full CRLs. Sorry Julien, there's a confusion here. The one I was talking about is the certificate extension, which is named CRL Distribution Points usually abbreviated crldp, while the crl extension you're talking about is named Issuing Distribution Point, usually abbreviated idp. This is the nomenclature used in RFC3280. You are right. Regardless, the other half of my response stands, at this time only full CRLs are supported, without critical extensions. Some reflexions about IDP. There's two cases : A - All revocation information for 1 certificate can be obtained from 1 crl B -revocation information for 1 certificate must be aggregated from several crl If the IDP does *not* use onlySomeReasons or indirectCRL, we're in case A, and the code can support the extension just by making sure that the cert matches the information inside the IDP (has a CRLDP that matches IDP's distributionPoint, is of the right type: CA, user, Attribute). Indeed, implementing case A should be fairly simple. Case B is the more complex part. I did not think it would be wise to try to support such a small subset of the extensions (crldp, case A). I think if and when the CRL extension work gets prioritized, most likely I would add support for all of them at the same time. The question stays of how the cache will be populated with all the needed CRL, and how the right CRL will be selected when checking a certificate. I see some of the #if 0 modification in certi.h suggest a way of handling at least the second part of this. Yes, in the header file - I started the design, but there needs to be code for this as well and there is not that much corresponding ifdef'ed code for XCRL in crl.c . ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: How to build nss release version
LiuPeng wrote: Does anyone know how to build nss release version in solaris,I use 'make nss_build_all' to build debug version,how to build release version? Just set BUILD_OPT=1 in your environment, then make nss_build_all . ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Getting the modulus length for sign vs. decrypt in NSS key generation consistency check
[EMAIL PROTECTED] wrote: I wouldn't mind some fame and glory, if I find the time I'll go for it... actually I am building a so called .NET P/Invoke Layer for NSS to give it to the Mono project. I have much mor side work to do just to get a decent number of NSS-compatible PKCS#11 modules and I regard NSS as the reference, since it is a part of Mozilla, the one-and-only widely used PKCS#11 application. All the Netscape/iPlanet/SunONE server products use PKCS#11, and are still also widely used. They also use NSS. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: CERT advisory CA-2003-26: Vulnerability in SSL
Nelson, Nelson B wrote: 3. If I'm not mistaken, NSS 3.9 *should* be a drop in replacement for NSS 3.7 and later, so it should be possible to simply install the NSS 3.9 shared libraries over the older ones in existing products. No need to wait for a new product release to use the new NSS. (Be sure to backup your old software and NSS databases first though. Your mileage may vary.) For example, I've installed NSS 3.9 DLLs into a mozilla 1.3.1 installation and it works just fine. If your application uses FIPS mode, you need an additional softokn3.chk file, not just the NSS DLLs . Otherwise you won't be able to turn on FIPS mode (a feature Mozilla actually supports). This file first appeared in NSS 3.8 - it did not exist in 3.7 . Julien ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: CERT advisory CA-2003-26: Vulnerability in SSL
POC wrote: Julien, Could you refresh my memory about FIPS mode? How do you turn it on in NSS (what API call) and if not on, what does that entail for an NSS app? FIPS mode is a higher security mode of operation. You will get a lot more token password prompts, and private keys cannot travel accross tokens even wrapped, among other things. To enable/disable it, please see the code in the modutil tool in pk11.c, specifically the FipsMode function. Also this softokn3.chk file: What is it for exactly, and does it need to be in a special location? I assume it's related to the softoken library which provides a software implementation of a PKCS#11 module. As Wan-Teh pointed out, the file should live at the same location as the softokn3 DLL/so file. On Solaris there are extra libfreebl*.chk files. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Getting a cert7.db format file from modern tools? What format for importing root CA into Netscape 7?
Mark, Mark Thacker wrote: So, two questions please : * Is it possible to convert a cert8.db into a cert7.db , or at least extract what I need out of it? No program exists to do that, only in the other direction. * What version of NSS (and NSPR) is needed to generate cert7.db formatted files ? NSS 3.6 or earlier will read/write cert7.db databases. Also, indeed older versions of Netscape generate these files as well, but how do you get the root CA into the browser's list ? You can load the file as a .DER or .CER file, and the browser will prompt you for trust settings. Most independent CAs will provide you with an HTTP link you can click to add their root CA to your browser. * Do you use 'certutil -A' with a copy of an existing cert7.db file, Yes, that would be one way to do it. can you import the root CA from disk if it's in the correct format (which format? PKCS #12, DER or what?) DER format. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: C_Initialize fails with segmentation fault
moonwulf wrote: Hello, I have a problem using the pkcs11 library. I am working under linux, and using gcc. I load the libcryptoki.so dynamically. Who makes that libcryptoki.so ? Is that a known good PKCS#11 library ? Please try it with an existing PKCS#11 application, such as Mozilla or the NSS tool modutil. It will call C_Initialize. If that does not work, then the problem is with your library, not your test program. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: On dividing CA selection effort between pre and post release
Jean-Marc, Jean-Marc Desperrier wrote: Nelson B wrote: Duane wrote (quoting me): I was under the impression, that mozilla (the browser) was like MS IE in that it automatically checked based on CRL urls in certificates... Once a mozilla user primes the pump by loading the first CRL, then yes, the rest can be loaded automatically. But there is no code to extract the CRLDP from the cert in Mozilla, it's not even displayable in Mozilla. If there were someone working on PSM, I wish it would have a good place on his todo list. Currently not only PSM but also NSS only support full CRLs, but not CRLDP. There is already some code in NSS to extract the DP from a cert, but it isn't currently used. The cert verification currently works something like this. Feel free to look at the source in lib/certhigh/certvfy.c, in CERT_VerifyCertificate for more details . 1) check for trust in certX.db . With explicit trust, all other tests are short-circuited. 2) check signature against issuer 3) check serial number against issuer's full CRL, if the CRL is available in any PKCS#11 module 4) check for OCSP, by making an outgoing connection. All checks are repeated for each cert in the cert chain, except for OCSP which is currently only done on the leaf. Generally, NSS avoids making outgoing connections during PKI operations. The OCSP check is one exception to the rule. I'm not sure that we want to add other exceptions to go fetch CRLs from the network within that blocking cert verification function. Also, most applications want to perform the networking (download) themselves. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: On turning CRL and OCSP checking on by default.
Alex, Deacon, Alex wrote: 1) Although the option to perform cert validation (either via OCSP or CRL) should be a user configurable option, I believe that the application should ship with this option turned ON by default. It would be nice, but I wonder how many users would complain about all the sites not working ... A lot of OCSP servers have been incorrectly (and that includes Verisign's). I think the option should be off by default for clients, certainly for CRLs, which get very large and are not suitable from most clients at low bandwidth under any circumstances. 2) The decision as to what mechanism the client should use to validate a cert needs to be dictated by the CA, not the user, using the CDP and/or AIA extension. So instead of a ca-by-ca config as you describe, I would rather see something like this - * If there is only a CDP , then the browser should fetch the CRL. This could be implemented in PSM. It would have to download the CRL and import it to the local database. * If there is only a AIA extension, then the browser should send an OCSP request. Currently NSS will automatically do an OCSP check if the AIA extension is present. This occurs even if the cert was checked against a CRL also. * If there is both an AIA and CDP extension, the browser must send an OCSP request first. If OCSP fails, then it should then fall back to using a CRL. This would require code changes to NSS. Currently the policy is to always check CRLs first (among the locally available ones in the database), then OCSP (if enabled). 3) All CRL's and OCSP responses should be cached locally by the browser, ideally the cert/crl cache would be separate from the standard web cache (which can be flushed/turnedoff/etc) The browser should never hit the wire if it already has access to a fresh (current non-expired) CRL or OCSP response. There is already a local (in-memory) cache in NSS for full CRLs. There is not one yet for OCSP responses. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: On turning CRL and OCSP checking on by default.
Hi, Deacon, Alex wrote: VeriSign has spent a lot of time and effort recently ensuring that not only do our OCSP services work, but that they will continue to work as the load increases. Clearly there is no excuse for any CA, especially VeriSign, to have a faulty OCSP implementation...especially if they are including the AIA extensions in certs they issue. I agree. I feel that cert validation is a very important part of PKI, and thus would rather that it be turned on by default. I agree that CRL's in this case are not the way to go...and this is why I suggested that OCSP (and not CRL's) be the default validation mechanism. I believe OCSP is indeed fine for clients and someday it may become the default. PSM should also take advantage of any caching HTTP headers associated with the downloaded CRL. Can you be more specific as to which headers you are referring to ? Currently NSS will automatically do an OCSP check if the AIA extension is present. This occurs even if the cert was checked against a CRL also. This seems like overkill to me. If the platform can determine the status via one of the mechanisms (or via a local cache), then there is no reason to re-ask for the same info via another mechanism. You could call it paranoid. But keep in mind that NSS is used by programs that are both servers and clients. NSS clients that need revocation can enable OCSP. Only the OCSP revocation check will be performed, in this case transparently by NSS, because the client has not explicitly downloaded the CRLs, so they are not available. NSS servers that need revocation (for client auth) have some code to download CRLs . Netscape Enterprise Server 6.1 features an in-memory PKCS#11 module (called revocator) that periodically downloads CRLs. When verifying certs, NSS automatically searches all PKCS#11 tokens for CRLs, and caches them. NSS servers don't typically enable OCSP due to the high performance cost of having one extra outgoing connection for each incoming client. So, the fact that NSS tries both CRLs and OCSP does not matter much, since usually only one is available by virtue of application configuration. I would still suggest that if there is no locally cached (non-expired) revocation info for a particular cert in the local caches, that OCSP be tried first...and then CRL's as a last resort only if OCSP fails. Technically, the revocation information from CRLs does not expire. nextUpdate only means the CA should have more recent information available, not that the CRL is expired. So I don't see it as wrong to still do the OCSP check. I understand your point about not hitting the wire if CRLs are available and have been checked - you want to reduce the load on your OCSP servers. As I said above, I just think most clients will not download CRLs due to size and the lack of browser-initiated CRL download process, and should enable OCSP as their only means of revocation. So the impact of doing this optimization in NSS on server load would be in my opinion minimal. If circumstances were to change and millions of clients started downloading CRLs, then maybe the double-check for OCSP also in NSS can be considered, but I don't see it right now. I think you'll have big server problems too if clients try to use CRLs . It's a bandwidth vs CPU trade-off. There is already a local (in-memory) cache in NSS for full CRLs. There is not one yet for OCSP responses. Great...are there plans to cache OCSP responses? The need is known, but no resources are currently assigned to this feature. It may become a priority in the feature, or not. If you want it really bad feel free to contribute the code to NSS. I can point you in the right direction, as I wrote the CRL cache and hopefully some of the code can be shared. http://bugzilla.mozilla.org/show_bug.cgi?id=48597 http://bugzilla.mozilla.org/show_bug.cgi?id=91532 http://bugzilla.mozilla.org/show_bug.cgi?id=205406 ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Proposed MF certificate policy and FAQ
Frank, I think you have just opened a big can of worms with this Certificate policy. - It should be called a Mozilla Certificate authority policy, not Certificate policy. I don't think there is any plan to include any non-CA certificates. - I think the term default certificate database is somewhat ambiguous. Technically, there is a built-in PKCS#11 module containing a database of root certificates and trust. This module is separate from the certificate database associated with each Mozilla profile. In fact, the root certs module/database can be removed by the user altogether and security in Mozilla can continue to function without it. I just had to point that out. The CA certs don't get added to the profile certificate database, unless their trust is modified. - I am not a lawyer, but I really think you are underestimating the liability issues for the foundation if it chooses to select certificates. Has the Mozilla Foundation hired a lawyer to look at the issue to make a determination of the liability risks the security policy exposes the Foundation to, or is the Foundation in the process of hiring one ? I would love to be wrong, but I think this is definitely something that needs to be looked at by a lawyer, because it's the sort of thing that could take down the foundation if not done very carefully. Just because Mozilla has a legal disclaimer does not mean that you won't be sued. Commercial software comes with plenty of disclaimers, too. - As the (soon-to-be-former) AOL/Netscape employee who has been doing most of the check-ins to the built-in root certs for NSS in recent years, I know I would not feel comfortable at all with a policy that is so arbitrary and void of verifiable objective criteria - section 4.1 in particular. - The current official certifications for commercial CAs such as WebTrust are extensive and expensive. They don't match 1 to 1 with the spirit of the Mozilla foundation, in that they may be overly restrictive on who can join the party. So they shouldn't be a sine qua non condition for inclusion. - Most users don't understand PKI security and are not able to make CA certificate trust decisions. And it would be indeed laughable to except them to be able to do so with a pop-up that simply shows a few fields in the certificate. Ever tried to verify a root CA certificate just by looking its contents ? What did you do, call a company's 800 number and check the fingerprint and public key to make sure it matched ? The point is, you need an external source of trust to help with the decision. There is no one-size-fits-all list of trusted CAs. That's why trust is editable, and not static. People are using Mozilla in diverse environments. I personally use Mozilla as if it were commercial software, for personal needs such as banking, and wouldn't expect it to include MyFriendlyNonProfitCAWhoCan'tAffordWebTrust, Joe'sPersonalCA, or MilitarySecretCA. In the later two cases, the end-users are savvy enough to install the certificates themselves, before they actually start to use them (ie. long before the browser pops-up an unknown CA - do you want to trust it? pop-up). You on the other hand might want to use MyFriendlyNonProfitCAWhoCan'tAffordWebTrust without being presented a trust pop-up that is very hard to act upon. Unfortunately, I don't know of any organization that will vouch for CAs in the MyFriendlyNonProfitCAWhoCan'tAffordWebTrust category, but it sounds like that's what you need here. I don't think it can or should be the Mozilla foundation itself doing it through its policy. I also don't think they should be blanket included together with all the commercial CAs that passed a certification. I think MF should defer to such a CA verification organization when one is created. When it does, these CA certs can be compiled into a separate PKCS#11 module containing only certificates CAs in this category. The Mozilla browser could then prompt the user for the security policy he wants to adopt when creating his profile : there could be a checkbox for the commercial CAs, which would basically be the current built-in module, and another checkbox for MyFriendlyNonProfitCAWhoCan'tAffordWebTrustCAs(for lack of a better term) who did not go through the WebTrust (or other) commercial certification required to be included in the first group. The effect of each checkbox would be to load or not load a given PKCS#11 modules containing a set of trusted CA certificates. 0, 1, 2 or n PKCS#11 modules containing trusted CA certificates can be loaded in Mozilla in any one profile. This way, the user makes the decision of which CAs he trusts on a rational basis when creating his profile with a question that he can answer. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Proposed MF certificate policy and FAQ
Frank Hecker wrote: Julien Pierre wrote: - It should be called a Mozilla Certificate authority policy, not Certificate policy. I don't think there is any plan to include any non-CA certificates. I originally called it the Mozilla CA Certificate Policy, but changed it just to have a shorter name. I can certainly change it back. Well CA cerificate is somewhat redundant (it includes Certificate twice). I would say Mozilla [built-in] Certificate Authority Policy would be a good name. But to play devil's advocate: It is 100% guaranteed that we would never ever want to include a non-CA cert in Mozilla? It is not guaranteed. You can use the built-ins module for anything you want, including negative trust on some known compromised popular server certs (ie. like a global CRL). But I would not recommend such use. I think in practice you would only ever want root CA certs on it. - I think the term default certificate database is somewhat ambiguous. Technically, there is a built-in PKCS#11 module containing a database of root certificates and trust. This module is separate from the certificate database associated with each Mozilla profile. In fact, the root certs module/database can be removed by the user altogether and security in Mozilla can continue to function without it. I just had to point that out. The CA certs don't get added to the profile certificate database, unless their trust is modified. I am open to using different terms and a simple way to explain what actually is done. Suggestions welcome. Well, I don't know yet what the right name should be, but if we choose to have several modules with different set of certs, then the distinction becomes more important since there won't be a single default certificate database. (MF officers, and the MF board if necessary), and recommend that they Make that require. Please forgive me now if I rant for a bit: I'd like to have a conversation about mitigating security risks, but people keep dragging me off to start a conversation about legal risks. Why is that? What is it about CA certs (as opposed to a host of other important security-related issues) that prompts this relentlessly single-minded focus on bad things that can happen from a legal point of view? (I am tempted to say, because with PKI and CAs the lawyers got there first, but I'll hold that thought for now.) Does it really need spelling out ? If you have a rogue or compromised trusted CA in Mozilla, which willingly signs fake server certificates, that opens the door to all kinds of scams, where Mozilla users will think they are doing business with somebody when in fact they are not. Remember that one of the most common uses of SSL is for financial transactions. If Mozilla users suffer financial losses due to a rogue trusted CA, you can bet they will sue whoever approved that trusted CA, disclaimer or not. So it is in the interest of the Foundation not to make the decision itself. Past a certain point I just don't understand why this is the case. I don't understand why we have to consult a lawyer before deciding whether to add a CA cert, and not when deciding how to best configure Mozilla security options for the typical user. (And in fact isn't the former just an special case of the latter?) You have a point. And I think the MF should have a good answer to that question, since it distributes all the security code, not just the CA certs. The liability situation is different now that there is an MF, rather than a corporate distributor of the open-source code. - As the (soon-to-be-former) AOL/Netscape employee who has been doing most of the check-ins to the built-in root certs for NSS in recent years, I know I would not feel comfortable at all with a policy that is so arbitrary and void of verifiable objective criteria - section 4.1 in particular. Then let's come up with some verifiable objective criteria -- but let's focus on criteria that mitigate security risks, as opposed to legal risks. The lawyers can take care of themselves. The policy will have to address both risks, for the sake of the MF and the contributors editing the database. - Most users don't understand PKI security and are not able to make CA certificate trust decisions. And it would be indeed laughable to except them to be able to do so with a pop-up that simply shows a few fields in the certificate. Ever tried to verify a root CA certificate just by looking its contents ? What did you do, call a company's 800 number and check the fingerprint and public key to make sure it matched ? The point is, you need an external source of trust to help with the decision. There is no one-size-fits-all list of trusted CAs. But of course the problem is that in this respect the Mozilla Foundation offers Mozilla as a one-size-fits-all product, in large part as a consequence of the design of the underlying security/crypto mechanisms. We can't easily offer Mozilla for casual Internet
Re: dbck
This tool has not worked in years, since the cert/key databases got moved to the softoken PKCS#11 module . It would be quite difficult to get it to work again. We still keep the source in the tree, but it is not buildable as you found out. Ariadne wrote: Hi, Has anyone gotten dbck to compile, whenever I tryin nss-3.9 it fails with various errors. Is it my system (gcc-3.3.1-16) or is there a prob with the library?. Some of my users are unable to export there private keys from within Netscape and I suspect the cert7/key3 are corrupt. Anyone got ideas? Thanks, Ariadne ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Proposed MF certificate policy and FAQ
Ian, Ian Grigg wrote: While you were worried about some mythical man in the middle sneaking in and stealing your password for no good purpose (the bank/fund would be covered against that in general), you were probably being robbed blind by your mutual fund. Those banking/fund protections may apply in some cases in the USA, but they certainly don't always in other countries. If someone steals your credit card number in France, you may still be liable. So SSL security plays a much more important role than you think. I know this from experience. I'm hoping that Mozilla can realise this. There is an opportunity here to restart the security process that has lain dormant for a decade. And a crying need - the threats today are from spoofs/ phishing, viruses, insider robbery, database hacks, and so forth - all of which need to be addressed by a wholistic approach to security, not by worrying about this cert or that CA covering a threat that doesn't exist except in the minds of cryptography academics. Certainly other attacks exist, but attacks on certificates are one type of attacks that is possible. I agree that indeed Mozilla should be reviewed for all types of attacks, not just crypto/certificates attacks, but not that we should ignore crypto/certificates attacks. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: On turning CRL and OCSP checking on by default.
Jean-Marc, Jean-Marc Desperrier wrote: So if you do CRL checking at all, there are good reasons to report this check as failed if you only have access to a CRL whose nextUpdate is in the past. Except of course if you have an date argument in the check that says Check validity for *this* date and the date predates the nextUpdate of the available CRL. First, let me point out that the RFC only recommends an algorithm to verify certificates and signatures on the current date, but not at dates in the past. Second, a certificate may be retroactively revoked, such as in the case where a private key was compromised, but the fact wasn't noticed until a week later. Thus, even if you have a CRL which nextUpdate is after the date you are trying to verify, this may not be sufficient. The latest CRL may still contain that certificate with a prior revocation date. There are even more intricate issues for certificates with retroactive start dates. This is again a case that RFCs do not preclude, and is impossible to detect, due to the lack of an issuanceDate field in the certificate. The point is, to do a truly accurate check according to RFCs, you can only verify a signature or certificate at the current date, with the latest currently available CRL. Anything else is best effort with unspecified behavior. Which NSS does try to attempt, but there is no guarantee on the results. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Proposed MF certificate policy and FAQ
David Ross wrote: Duane wrote: We are talking about MONEY and PRIVACY. How much risk are you willing to take with these? So I take it you remove a lot of certificates from your copy of Mozilla then? I have disabled all CA certificates on my PC except those of the three CAs vetted by the California Secretary of State, plus one other vetted by my ISP. I'm not deleting the others (just disabling them) because they might be accredited or otherwise audited in the future, and it's too hard to get new copies. The only way to delete the other built-in certs is to remove the built-in module altogether. Otherwise, you can only remove the trust. Which in practice should have the same effect. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Proposed MF certificate policy and FAQ
Duane, Duane wrote: Those banking/fund protections may apply in some cases in the USA, but they certainly don't always in other countries. If someone steals your credit card number in France, you may still be liable. So SSL security plays a much more important role than you think. I know this from experience. What if they steal your credit card, not because of the certificate, but because of weak security in protecting it in storage? You would still be liable too. Security is after all about the weakest link, what point is there auditing CAs if you don't audit the hosts interacting with finacial information after you send it over the net? The point in auditing the CAs is that it's better than not auditing the CAs at all. Certainly other attacks exist, but attacks on certificates are one type of attacks that is possible. I agree that indeed Mozilla should be reviewed for all types of attacks, not just crypto/certificates attacks, but not that we should ignore crypto/certificates attacks. And how often has it happened I think you'll find is his point, not often if at all, they don't need to use ssl, just look at how much money is lost every year to 419'ers If that's his point, then I completely disagree with it. Just because every other part of Mozilla does security reviews wrong (or not at all) doesn't mean we also should do the same for the NSS and other security components of Mozilla. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Proposed MF certificate policy and FAQ
Ian, Ian Grigg wrote: So SSL security plays a much more important role than you think. I know this from experience. You have experience of someone stealing your credit card over a connection? That's something I'd like to hear about. It would be very useful to apply some statistics to the situation. No, I know from experience that if you have a bogus transaction on your card in France, it's up to you to prove it, and the bank will not automatically reverse it. You have to file police reports and so on. It's very painful. I know several other people to whom it happened over there, as well. I don't know for sure how the card numbers got compromised, but through an insecure connection is a strong possibility, since retail transactions in France use smartcards, not magnetic stripes, and more than just a number is required to authorize any retail transaction. The number method is only used for remote transactions (mail order, internet). I also know someone in the US who lost her credit card number over a connection. She did a non-SSL transactions (with a business that didn't have a cert) on a university network. And other students were snooping on the connection and collecting numbers. How much time is spent arguing about crypto/cert attacks? How much time is spent coding for phishing attacks? How many of each attack occur, and how much are people losing on each attack? In the sector I've spent most of my time monitoring, DGCs (digital gold currencies) I've seen maybe 50 phishing attacks. One used SSL. None were protected by the CAs. Zero, zip, nada. That shows that current SSL security with trusted CA is rarely attacked. We should not lower the value of using SSL in this model by adding random CA unaudited certs without distinction. The entire discussion of CA certificate policy is about the SSL with trusted CA case. Any other case is irrelevant to the CA policy discussion, IMO. The other cases are relevant to browser security preferences and defaults. And I'm all for having more security warnings on by default. But it's another discussion. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: bad certificate database
Jean-Marc, Jean-Marc Desperrier wrote: Wan-Teh Chang wrote: If you would like to see this fix in NSS 3.9.1, please add a comment in Bug 53133 and we can work with John Myers to get his fix into the right NSS cvs branch. I did that, and I could also verify it as fixed in the Mozilla trunk. [...] I suspect you would need to delete the old certificate and install the certificate again with the new binaries of NSS 3.9.1 (or 3.10) that has the fix for bug 53133. This sounds bad :-(, because it seems the certs affected by this problem can't be backuped (see dependant bug 217305) Here is what I would do : 1) backup your cert8.db and key3.db files 2) remove your key3.db 3) delete the cert in current Mozilla 4) upgrade to the NSS version that fixes the problem 5) restore your old key3.db 6) reimport your public cert from the CA This should preserve the private key in key3.db, and is probably the only way to do it if the key was generated in the token (not escrowed by the CA), and you were unable to back it up yourself. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: On turning CRL and OCSP checking on by default.
Jean-Marc Desperrier wrote: Currently the defined maximum for NSS is *infinite*. If there's any crl available for checking, however old, the check will *never* return crl outdated. This is not configurable. This in my opinion makes the CRL checking in NSS ineffective. When the NSS chech says check OK, a user that wants to know if all CRL used in the check were really up to day, needs to reimplement almost the whole certificate chain verification to do that. This was recognised as a problem in bugzilla. And probably there's nobody available to correct that. But I can't get the logic of saying it's not a problem. Indeed, this is bugzilla 233806 . And while today is my last day at AOL, I will still be working on NSS at Sun from tomorrow. I can't say what the priority of this bug will be over there, but I can tell you that there is a good chance this bug will get fixed, inside or outside my job responsibilities. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Proposed CA certificate metapolicy - 7. threat models
Ian Grigg wrote: Jean-Marc Desperrier wrote: I didn't say exactly that. I reported I heard the level of protection is lower in America, but I don't have the exact description of the difference, I might even be proven wrong. Or it might be different depending on the state. I also was surprised, so I asked someone who hopefully knows better (an american). It turns out that there are no laws on the books that specifically limit the liability of owners of credit cards, in the USA. At least, from that one person's perspective, I could also be wrong on this point, and we may want to dig further. You got an incorrect answer. Please see : http://www.bankrate.com/brm/news/DrDon/20020617a.asp?keyword=CREDITCARDSauthorid=12firstn=Donmiddlen=lastn=Taylor * Unauthorized charges. Federal law limits your responsibility for unauthorized charges to $50; However, the protection only applies to credit cards (ie. line of credits) because it is part of the Fair Credit Billing Act. If you use a US debit card, you are not legally protected by this. In that case, it is up to the bank to tell you how much you may be liable for in case of fraudulent activity, according to their policy. It may range from $0 to unlimited. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Proposal : Installable trusted CA list
Roger, rhkelly wrote: So this proposal would be that Mozilla would get away of imposing to all users a single built-in trusted CA, but instead distribute several trusted CA list, with a description of the origin of each list, how it is created, and let the users decide what is best for them. This is clearly the way to do it. In addition, the format of such list should be defined and documented, so that special-interest user communities can become their own trust-list publishers. That's a totally different proposition. What's being discussed is the content of one or more built-in trusted certificates list. Currently, the one built-in in list is contained in a PKCS#11 module that's compiled at the same time as NSS. This is a platform-specific file, and is not suitable for download or user installation. It's already been pointed out that it's very difficult for the user to make rational trust decisions about a single root CA when connecting to a site, and making decision about lists of multiple root CAs at download time are even harder to make than for one. Several formats already exist to distribute more than one certificate, such as PKCS#7. It would be up to Mozilla to bring up trust dialogs for each of the certs in the package. I don't know if it does that now, I have not tried creating a PKCS#7 of multiple root CA certs. But I think it would not be a good idea to have Mozilla trust all the certs in a package. Just giving this option is inviting security risks. Who is going to be able to really verify the entire list, if they don't even know how to trust one ? Clearly the better model is to have the trust pre-installed in the client. That may mean using non mozilla.org-binaries in some applications (eg. government, corporate) with an alternate built-in root cert module, but it is much more secure than having the user install the trust manually afterwards. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: On turning CRL and OCSP checking on by default.
Jean-Marc, Jean-Marc Desperrier wrote: Julien Pierre wrote: First, let me point out that the RFC only recommends an algorithm to verify certificates and signatures on the current date, but not at dates in the past. I don't want to strech the whole discussion any longer, but if you are actually interested in that sort of things, then have a look at RFC3126, Electronic Signature Formats for long term electronic signatures. This is an informational RFC, but the ETSI TS 101 733 document it's based on is a european standard for long term signatures. Which requirements have also been included inside the XML XAdES format. Which explains why european institutions are currently investing in that format. Thanks for the reference. I am indeed interested and will be reading up on it. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Proposed MF certificate policy and FAQ
Jean-Marc Desperrier wrote: You mean a bank *operating* in France, Julien ? If that's so, that's a disgusting thing to do. You can call any consumers' association and denounce that. If your bank really did that, they lied and cheated you. Yes they did ... The french law is very clear. You can not be held liable for a transaction if neither your signature, nor your secret code was used. You only need to write a letter to repudiate it, and if they still want to charge you, the burden of proof that the merchandise was actually sent to you is on them. http://www.legifrance.gouv.fr/WAspad/UnArticleDeCode?code=CMONFINL.rcvart=L132-4 Your problem may have occured before 2001, but that law did nothing but explicit the jurisprudence that existed before that date. It happened to me before, to my mother after. I also know someone in the US who lost her credit card number over a connection. She did a non-SSL transactions (with a business that didn't have a cert) on a university network. American are not as protected by law as French people are, and this kind of things can be a much larger problem in the US. That's not actually the case. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Proposed MF certificate policy and FAQ
Ian Grigg wrote: I also know someone in the US who lost her credit card number over a connection. She did a non-SSL transactions (with a business that didn't have a cert) on a university network. I'd be interested in establishing that - this is the first time I've ever heard anyone claim that an actual case of a credit card being lost over a connection. Well, now you have heard one. What do you want me to do to prove it, give you the person's name, e-mail and and phone number, the name of the university ? I do have that info, but I don't believe she would want me to share it. Also, I have seen legitimate (but security-ignorant) businesses that ask for credit card numbers by insecure e-mail. And very likely many security-ignorant customers will just volunteer the information over insecure e-mail. I don't need to tell you how vulnerable that is to snooping by all the ISPs and relays, or any thief in between. I don't have any stats on it, but I bet it's a significant cause of fraud. And, I've been looking for the last decade or so... Where ? What was your research based on ? Did you ask the banks for their statistics on credit card fraud ? Try asking the US credit card processors why they charge a higher rate for online transactions than for retail transactions. I don't think they are just greedy (though they certainly are), but online fraud is a significant problem to them and they compensate for it by higher rate. However, it may be difficult to establish in many cases how exactly the credit card numbers were compromised since there are so many different ways. And the thieves probably don't go and brag about the most popular methods. More secure technology would reduce the processing rates and benefit both merchants and consumers. The rate on smartcard transactions in Europe is much lower than the rate for VISA/Mastercard, even retail. Most businesses in Germany stopped accepting VISA/Mastercard because they didn't want to pay the high processing rates. The foreigners have to pay cash, and nationals all have smartcards. That way German business doesn't pay the 2-3% that get you free frequent flyer miles. They either pocket the difference in profit, or have lower prices. Is there any documentation on this? Is there any indication that the card was in fact lost over the network, rather than being hacked from the business's computer? Any correlation between the thief and the victim? Or was the card maybe lifted form the dorm room? I don't know the answers to those questions. I only know what she told me about 4 years ago when she was in school - that someone stole her credit card number after she made an insecure transaction on the university network, and a bunch of transactions that weren't hers appearing on her statement soon after. She knew this for a fact because it had happened to other people as well and word had gotten out that there were people snooping on the university network (but they had not been caught yet). I couldn't help but give her a little lecture on security, as she was doing an internship in the Netscape/iPlanet web server, where I was working on security. I haven't been in touch with her since. I think the only ones you would be able to check the story with are those with whom she shared it personally, such as me, or the bank, which obviously had to be notified of the fraud to reverse the charges, but wouldn't necessarily know the exact cause of the card compromise. After they reversed the charges, they canceled the old card account number, opened a new one with a new number, and sent her the new card very securely ... via US postal mail. I believe this to be very common. And this is one of the key risks SSL tries to protect against. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Proposed MF certificate policy and FAQ
Ian, Ian Grigg wrote: The point in auditing the CAs is that it's better than not auditing the CAs at all. It's not an absolute. There is no point in auditing the CAs if it achieves little or nothing, in terms of security, and costs money. True, but I lost you after the if. I think the current audits are a useful attempt at establishing identity of peer certs, if not a guarantee. They may cost, but I consider them to be a very good value for money, vs not auditing and simply trusting any random cert without verification which in consumer environment would basically make SSL worthless. The reason that Frank wrote his policy on these points, presumably, is that it's not clear that audits of CAs deliver value for money. I did not see him write that. I think he was happy to accept audited CAs, meaning that he did attribute some value in the audit; but that these audits were not all things to all people. Ie: for people who have no money, they get no value from no audit ... It's one of my points! Another of my points is someone has to pay for it, even if it doesn't happen. So, a good security view will ask, what's the value for money here? The end-user or the Mozilla foundation. the one paying for the audit of the CA certs. The CA is paying for the audit. The end-user may be subject to more scam/fraud by doing SSK transactions with certs issued by unaudited CAs. The value of trusting only auditing CAs to me is clear, reduce this type of risk. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: PKCS#11 - Transient Certificates/Keys
Jon Maber wrote: The question is this: is it possible for the server that issues/stores user certificates to instruct the PKCS#11 Module not to store the private key (or certificate) in any kind of persistent store? There are two scenarios where we might want to apply this, 1) when the browser generates a key pair - because we may choose to issue the user with a very short lived certificate every time they log in. If you generate the keypair locally, you have to do it with a given PKCS#11 module : ie. persistent NSS security database, temporary key object, or smartcard with 3rd party PKCS#11 module. The server can have no guarantee that the key won't be persistently stored in whatever device it was generated. You could wish to modify the software to generate the key only temporarily and not store it, but it could be circumvented by modifying the software. It sounds like what you want to do is have a short validy period on the certificate that is issued, and/or have the server automatically revoke the certificate. That would of course assume that all your other infrastrcture pieces support revocation, either through OCSP or CRLs. 2) when we deliver the private key along with the certificate - because we may choose to generate the key pair server side so we can create a long lived certificate and simply reissue it. Of course we would also like to avoid the need for a user to ever set a master password in the browser. If you generate the keypair on the server side, the only practical way for the client to use it is to deliver it to the client, which can then do whatever he wants with it - legitimate or not. There is nothing you can do against that. You will only waste cycles on your server side generating the keypair. Look into regenerating keypair on the client and having the server issue the cert at login time, and use revocation mechanisms for access controls on backends to check the certs. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Proposed MF certificate policy and FAQ
Duane wrote: Julien Pierre wrote: I don't need to tell you how vulnerable that is to snooping by all the ISPs and relays, or any thief in between. I don't have any stats on it, but I bet it's a significant cause of fraud. I rate this about the same as companies that get credit card information from people talking on mobile and/or cordless phones... They are both prone to interception as email is, but how many details are transferred by this method, either spoken or typed into a keypad... Surely any form of encryption is better then in the clear? Only if you are encrypting to the correct party, and not to a thief. This is why we have CAs and trust. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Proposed MF certificate policy and FAQ
Duane wrote: Julien Pierre wrote: Only if you are encrypting to the correct party, and not to a thief. This is why we have CAs and trust. Ian made a point of this about a Gold company using a self signed certificate and not having a problem. At this current point in time if I were a thief, there are numerous ways of getting information out of people for not much more then the cost of a pen. So is all the fuss about security so over rated to the point that people resort to using unencrypted emails, and unencrypted websites just because security is too costly or too difficult? I'd say yes, the first site (say google for example) their browser will tell the user about entering information into unencrypted websites, the user will dismiss that dialog box because they are only doing a simple search (by default it won't come back). I guess I am the only one in the world who has that option turned on, the dialog does come up for every one of my google search and other posts. And I know to watch for it when I submit sensitive data. It has come up on a few occasions. In Mozilla, the dialog is on by default. And if you click continue, the dialog will come back. You have to explictly uncheck alert me whenever I submit information that's not encrypted. Perhaps we should have another dialog explaining to the user in plain english but with more detail what they are really doing by disabling this option, with a second confirmation dialog. It should stay enabled. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Possible way to increase Security
Duane, The idea is good, but as you point out, protocols such as LDAP already exist to do this. What's missing is a global (worldwide) directory that's independent of a particular corporation of government. The key problem is that no one entity would have the resources to host such a server. Some distribution is necessary. Your protocol proposal is overly simplistic and does not address this issue, or the missing link of where the database of certs actually comes from ... These topics have been discussed extensively on IETF pkix and smime mailing lists, but no solution was found. You should look at the archives and look for my name in there. I definitely agree with you that the need exists for a global directory that can map email address to certs. This is a gaping hole in global PKI usage. But not an easy one to solve. Duane wrote: I'm currently drawing up a proposal for an independent submission for an Internet Draft and I'm after feed back on this. My idea is pretty simple, if all you have is an email address of the person you want to email, and they have a public certificate listed in the system, client software should be automatically be able to retrieve the certificate and encrypt email to the person without any intervention from the user. This would be particularly useful for web mail services and 802.1x key handling, as all you need is the email address, not a bunch of certificates. The currently level and ease of use of cryptography is pretty poor, and perhaps that's understating it somewhat, to address this I started thinking about a whois type service to distribute certificates, and it ended up somewhere a cross between a finger service and a PGP Key Exchange. Basically you connect to a tcp port on a CA service that interacts with a database, you supply an email address or a host name and the system replies with the current valid certificate which can then be used to encrypt data. For the full draft + example daemon code to achieve this go to: http://www.cacert.org/index.php?id=26prob=8 ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Proposed CA certificate metapolicy - 7. threat models
Hi, Jean-Marc Desperrier wrote: Julien Pierre wrote: [...] My experience is that's more protection than is afforded to credit cards in France. In particular, the quality of goods provision means that most US merchants have flexible return policies. I have tried returning stuff I bought that I was unhappy with in France (with a credit card). No luck : it's up to the merchant, there is no law that gives this right. [...] In my case it was brick and mortar. And the store wasn't willing to even exchange the item for something more suitable. The law was on their side. Still Visa Gold and some other equivalent cards include a usually very little known and used, but still amazingly powerful insurance that enables you to get a full reimbursement if you're not satisfied with a purchase you made with the card. Yes, but try actually using that insurance sometime. It typically has exclusions for foreign purchases. My US-issued platinum VISA credit card certainly did, so I was stuck with the item bought at retail in France, with no way to return or exchange it. I should have known not to buy retail. Anyway, end of this off-topic story. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: On turning CRL and OCSP checking on by default.
Jean-Marc, Jean-Marc Desperrier wrote: Julien Pierre wrote: You can however implement what you want without NSS changes, by wrapping the NSS certificate verification function. By effectively reimplementing a certificate chain build algorithm. Extending it is more like it, since you reuse the code that's aready there and don't reimplement all the other checks. Your algorithm is simple, because it handles only simple cases, but full implementation of rfc3280, cross-certification, policy constraints, handling cert renewal where the old CA cert is signed by the new cert makes this more complex. Cross-certification and policy constraints are explictly not supported by NSS at this time. You were only asking about a way of changing the CRL checking, and I provided you with an algorithm as a workaround. I do agree that to get to full RFC3280 compliance, the cert chain verification code in NSS needs to be rewritten. I can't predict whether that's going to happen or not. I'd prefer to create a patch for NSS where : - we can have an optionnal maximal age paramater for revocation information Again, please see bugzilla 233806 about this. - we can optionnally store a list of the CA up to the root with the revocation information for each of them. Can you detail the format of such a list that you propose ? Where would you want to store it ? In the softoken (cert db) ? ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Proposed MF certificate policy and FAQ
Jean-Marc Desperrier wrote: Julien Pierre wrote: [...] I guess I am the only one in the world who has that option turned on, the dialog does come up for every one of my google search and other posts. And I know to watch for it when I submit sensitive data. It has come up on a few occasions. In Mozilla, the dialog is on by default. [...]. Perhaps we should have another dialog explaining to the user in plain english but with more detail what they are really doing by disabling this option, with a second confirmation dialog. It should stay enabled. Nope. We need a better, less intrusive solution in terme of GUI. This one will always be disabled by users in 99% of cases and saying they're stupid will not change that. A really working system can only be an advance warning it seems. The lock icon is probably in the right direction to do this, but is unfortunately completely inedequate (it doesn't tell you at all if the form will go to an encrypted page). Maybe we need a lock inside the form entry ? With a different visual aspect based on the level of security ? But then we'd need a way to forbid a page to simulate the same behaviour using dynamic html. Maybe the trick would be instead to use a visual warning the form is unsafe, it would be a lot easier to make sure this warning can not be removed by dynamic html. Ultimately what it comes down to is : we want checks and warnings if the user is entering sensitive and/or financial information, and we don't want them in other cases. There is no automatic way for the browser to distinguish the correct behavior when a user connects to a particular server. The option is currently set on a global basis. Perhaps we should have a better system of policy selection than a global preference buried in a menu. Maybe it could be a frame for the browser window : red means no insecure submission check, green means check. The user would be able to open either type of window, which would set the policy to warn for everything that happens within it. He would have the ability to start either type of window (start sensitive browser window ? start regular browser windows) or toggle the policy (strict / not strict) which would be clearly marked by the frame color. The policy could also be saved as attribute for each URL in the bookmarks file, so when you go to your bank, it can force the policy to strict (and at the same time show it with the appropriate frame color). And for thing like google you could bookmark it with the non-sensitive policy (add bookmark would save the current policy). Of course the visual indicator could be something else than the frame color ... But it needs to be prominently visible. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Invalid certificate alert
Henrik, I thought the message made it quite clear that it is a problem with the server. There could be a lot of reasons for this, but the main one is somebody is trying to play CA and does not know the rules of PKI. They may have issued multiple server certs with the same serial number, or even your client cert with the same serial number as their server cert. That's not legal and that's why Mozilla tells you. You need to contact the server administrator as instructed. We have a bug in bugzilla that explain this in more detail, but I can't recall the number right now. Henrik Gemal wrote: I'm having problem accessing sites where I have to present my digital signature. I'm getting the error that's attached. I have no idea what it means. And the text in the alert box isn't clear enough. Is it a problem with my certificate or the server? ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Invalid certificate alert
Henrik, Henrik Gemal wrote: Thanx for the into Pierre. First name is Julien actually... 2 Could you help determine the cause of this alert to I can report it to the server admins. I narrowed it down to these URL. To reproduces first go to: https://i.tdconline.dk/tdco/gfx/local/sso/knap_q.gif then go to: https://bestilling.certifikat.tdc.dk/csp/authenticode/README and you get the error. I couldn't reproduce the problem browsing these two URLs with Mozilla 1.6. Try with a brand new profile and a fresh mozilla. The serial number is most likely in conflict with one of the permanent certs in your database . That could be either your personal certificate, or one of the intermediate certificates . Look at the serial numbers in the entire certificate chain, not just the final certificate (end entity). ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Proposed CA certificate metapolicy - 7. threat models
Gervase, Gervase Markham wrote: Frank Hecker wrote: There's still the trademark issue, but I don't see why this couldn't be handled consistently with other localization-specific changes. For example, if the Mozilla Foundation allows the creators of the France-localized version to include, say, default links to French search engines, and still use official Mozilla logos, etc., then I don't see why the Mozilla Foundation wouldn't also let them make changes to the list of included CA certificates, if there are good reasons for such changes. Removal wouldn't present a problem. Adding new CAs to the default list while still retaining our trademarks would be much more of a can of worms. Gerv Actually having separate builds for localized versions is a can of worms in itself. Are the localized builds built from separate branches ? I was under the impression that they simply had additional language modules. However, if you want a different list of trusted CA for each localized version, you may have to branch mozilla/security/nss/lib/ckfw/builtins for each country You won't just be able to install language modules, you will need to pick up new libnssckbi.so . ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Invalid certificate alert
Jean-Marc, Jean-Marc Desperrier wrote: But the fingerprint of the two certificates do not match anymore, so NSS reports them as two different certs with the same serial number. Maybe for *that* particular case, NSS should use a fingerprint based on the signed part of the cert. It is annoying to not be able to use the cert, because of an error on the unsigned part of it, that certainly has nothing to see with the ca, but some mistreatment later. I disagree that NSS should blindly accept these certs, on the contrary I think it should detect the encoding error. First, both NSS and OpenSSL are now using the same algorithm to compute fingerprints - on the entire certificate encoding, not the signed part. We had complaints that it was different and made it match (I don't remember what the difference was, as I didn't write the fix, I think Nelson did). So, if we change NSS to compute the fingerprint differently, then it will not match with OpenSSL's fingerprint once again. Second, certificates are supposed to be DER-encoded, which means Distinguished Encoding Rules, precisely so that there can only be one possible encoding for them. This case clearly violates it and the server or CA operator should fix it. NSS should be able to detect it. If it did, we would have known from the beginning which one of the two certificate chains was bad. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Invalid certificate alert
Jean-Marc Desperrier wrote: I didn't require that :-) I believe this also means you use the same alg as Microsoft CAPI which makes things simpler for everybody. And the specification for that algorithm would be where ? The signed part of them should. The unsigned part is not required to. Can you give any pointer to specs that document this ? In fact, openssl used to produce all certs with some BER elements in the unsigned part in the earlier versions (0.9.4). And as many CA don't issue truly DER encoded certificate, every toolkit just has no choice but to support it. Actually, NSS has not supported any BER encoding in certs since version 3.6, about a year and a half ago, since the QuickDER decoder was introduced and used in the cert dedcoding, as opposed to the more versatile but much slower BER/DER decoder. This padding issue is the first one I hear about that points to BER encoding in certs. So, perhaps CAs really do issuer DER certificates ? Or users of CAs that don't aren't using any NSS-based products such as Mozilla. Therefore, opposite to what I thought before watching in exact details, the version that has one unused bit set is the correct DER encoding version, and the one that does not set one unused bit, but instead includes it with a value of zero, is BER encoding and not DER encoding. The decoded value of the signature is exactly the same in the two case, so it's normal that signature verification does not fail. No, they are two different cases. The example you cite in the key usage is not a plain BIT STRING, but rather a named bit list, and the DER encoding for that dictates the shortest possible encoding, which in this case means truncating the upper byte if all its bits are 0, and removing the upper bit in the lower byte, if it is zero. Signatures are encoded as plain BIT STRING, not a named bit lists. The DER encoding rules for it specify that upper bits should not be removed even if they are zero. Imagine a 2048 bits RSA signature that just happened to have all 1024 upper bits set to zero. If encoded as name bit string like key usage, it would be indistinguishable from a 1024 bit signature. The DER encoding for BIT STRING must only remove the bits that are not part of the string, not all non-significant zeroes. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: It is OK now, BUT another part failed.
Benjamin, Make sure to use gmake 3.79 or later on windows platforms. ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Missing function dbopen in nss3.dll
Pradnyesh Rane wrote: Am I missing something while building NSS? Was dbopen function dropped/added in between versions? In NSS 3.4 and later, the database code was separated in a PKCS#11 library called libsoftokn3.so . Also, I don't believe the dbopen symbol is exported from it . I'm not sure why the LDAP SDK would be depending on that symbol. It sounds like you will need a new LDAP SDK that's compatible with current versions of NSS. If that LDAP SDK is itself a shared library, you might be able to get that working. Otherwise you will have to wait for newer versions of iPlanet servers that work with current NSS (sometime late this year). ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Where to find bare-bone DSA-like authenticated signatures gneration/verification code?
Ian Grigg wrote: It seems to be that every new product there is faced with four choices: 1. do no security; 2. do a quick and nasty home built hack of a protocol; 3. create a good, aligned, secure, precise and appropriate crypto protocol; 4. use a standard tool that is already built, reviewed, tested and safe. Everyone suggests 4., but, that's too hard, because one still has to select the right one, or to pick the wrong one and then slave through the horribly hard API and all the special hooks and the must-do-else-your-cat-fries security parts... So, 4. is out. Sorry, SSL guys, it's just too hard. Then, 3. is easily dispensed with, as those wunderkinder just don't exist. Which leaves 1 or 2: Nothing or somthing really quick and dirty, and probably only somewhat secure. This is the SSH story. SSH 1 was widely thought to be pretty loose. What happened? It succeeded, partly because the author didn't worry overly about having perfect crypto - he rocked on ahead with something that was ok. I have left a lot of your posts unanswered as I could have gone on for ages, but I couldn't let this one slip. What is your criteria for comparing the respective success of SSH and SSL ? I bet the later gets used by a heck of a lot more people every day, and it is supported by many more programs. You are free to use any proprietary security protocol you want, including a home built-one or double ROT13 . Nobody is forcing you to use SSL/TLS for your own applications. Obviously most businesses and financial institutions don't agree with your approach, as they prefer to use the open and very popular SSL/TLS protocol, which is supported by a host of programs from many sources, commercial and free, rather than reinvent the wheel and start from scratch as you advocate. One of the often stated goals of the NSS library is to support this SSL protocol, for the now-defunct Netscape client, the Mozilla client, some other AOL clients, the Sun/iPlanet servers, and incidently anyone else who wants a free source implementation of that protocol. Supporting proprietary security protocols is not one of the stated goals of NSS, or of Mozilla . ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
