Re: MITM in the wild
Eddy Nigg wrote: Nope, just eliminating an assumption or two: identity required for court. Once these are eliminated, life becomes much easier. Real identity is required for court, No it's not. You just need the person, not their identity. The identity is useful for eliminating mistakes, of course, and the court will look at that aspect. That's its job. If you need to get someone in court, they either come willingly, in which case nothing is needed, or you need to find the person. This requires either a physical address and a service of summons to the person, or in webcommerce, courts will these days accept an email address if the circumstances are appropriate (e.g., that's how he closest you got when doing business). So, if you were looking at resolving disputes -- are you? -- then you would look at how to get the person into a forum of dispute resolution. If that is the service that you are looking to offer the person, then it needs to be tuned to do that. why eliminate it? Because if you claim that it is needed to resolve disputes, then this may be deceptive. (At the least, you should figure out why it is needed and use that reason.) According to my preference I may freely decide in order to give somebody access to certain resources which are truly under my control, I may require a verified identity too. It's about the risk assessment of each of us, being it private or corporate. OK, I buy that. Would you sign to that as a principle? iang PS: longer reply later, no time today, apologies. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MITM in the wild
On 11/12/2008 08:32 AM, Ian G: eBay users seems to survive without them? Because a different body governs them. Or lets make some comparison to transportation, where one in order to drive a car must undergo some training and carry a license. I could imagine something similar applied to the Internet, where one carries a license in order to drive on the network. Anybody without a license can't drive along. Sure. This is nothing to do with *identity* tho, all it has to do with is ones tested ability to drive safely. Try this thought experiment: would a driver's licence without a name on it, but with a photo on it, work as well? No, because the license is tied to the person. His identity details are part of the license document. Right, certs without names or with nicknames achieve that. It might not be possible to see the name, but seeing the issuer is sufficient to say something. If a trail is all that is required, this can simplify things a lot. Right, if the issuer could confirm that the subscriber has disclosed his details and was confirmed by the issuer (whatever procedure is not imported for this exercise) and this is his identification number (some random number issued by the issuer), it could be sufficient for most operations. The protection is still real even though the certification doesn't include the details of the subscriber. Well, except there isn't much in the way of use cases. On the roads, bad drivers keep bumping into each other. Of course. Actually we aren't concerned about bad drivers and accidents on the net, but about deliberate damage. This includes also spam etc. Of course. There shall be no difference from when I walk into their shop or buy from the web site. Ah, but there is, that is the point. Well, for the legal system there is very little difference, it's your ability to pursue which is limited. The point is: do CAs require this so-called legal identity? Obviously that's the way to reach an entity, being it a private person or company. Let's call it for sake of discussion a privacy issue. If so, then it should not be required unless needed. I think that's correct and is also applied today (i.e. your web log doesn't require to disclose your identity, hence DV would be perfectly fine). If the answer is, so relying party can take the subscriber to court, then we have a problem: it won't work that easily, indeed it is bordering on useless, because the more borders we cross, the more the transaction costs go up. And everything should be with reason. Nope, just eliminating an assumption or two: identity required for court. Once these are eliminated, life becomes much easier. Real identity is required for court, why eliminate it? According to my preference I may freely decide in order to give somebody access to certain resources which are truly under my control, I may require a verified identity too. It's about the risk assessment of each of us, being it private or corporate. And, for a dispute, you do not need the verified identity. You need to find some way to get the person into court. ...and how do you get the person into court if you don't know who the entity is? I don't understand what exactly you discovered? -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
SSL version 3 - How Firefox contructs key materials for 3DES
I've been developing a web server (research) based on ssl version 3 doc (ssl-version3-02.txt), choosing cipher suite 0x000a (ssl-tripleDes-sha) and using firefox browser to test the program. It works successfully from client hello until server finished (handshake protocol). All key materials (MAC secrets, cihper secrets and initial vectors) seem to be correctly produced. But, there is a problem when it tries to process the first application data sent by firefox (decrypting the data). The first block (8-bytes) of the result (plain text) is meaningless (the rest blocks are correct). I suspect that the initialization vectors used is this program is different than the one used by firefox(client). Is there anyone can share or explain why it can happen, because it uses the same key and IV when verifying the client finished message successfully. As an illustration, received application data: ?Z?ZZ^%TP 1.1\n.. which is supposed to be GET / HTTP 1.1\n.. Thanks ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Help to use PKCS 11 functions in firefox extension
Akkshayaa Venkatram wrote: Hi I am developing a Firefox extension that calls PKCS 11 functions like C_Encrypt, C_Sign, C_Decrypt and others.. We don't expose the direct C_ calls in NSS. NSS typically has the token open during the entire time, so applications making calls and changing states could cause some issues. You can still access the functionality through the PK11 wrapper functions, but not many of those are exposed in javascript. I am not sure how to call these functions from the javascript file. I have an idea that i must wrap these C functions in XPCOM-IDL. But not sure of how to do it..and what XPCOM IDL to use. Yes, The actual C functions you need to wrap are defined in pk11pub.h. I usually look at some of the mozilla extensions built into the mozilla tree for examples on how to build an XPCOM file. This is a generic question which you can get a better answer on how to create xpcom objects in C and call it from javascript in the xpcom mailing lists. bob smime.p7s Description: S/MIME Cryptographic Signature ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: SSL version 3 - How Firefox contructs key materials for 3DES
Rusdy13 wrote, On 2008-11-12 02:25: I've been developing a web server (research) based on ssl version 3 doc (ssl-version3-02.txt), choosing cipher suite 0x000a (ssl-tripleDes-sha) and using firefox browser to test the program. It works successfully from client hello until server finished (handshake protocol). All key materials (MAC secrets, cihper secrets and initial vectors) seem to be correctly produced. But, there is a problem when it tries to process the first application data sent by firefox (decrypting the data). The first block (8-bytes) of the result (plain text) is meaningless (the rest blocks are correct). I suspect that the initialization vectors used is this program is different than the one used by firefox(client). Is there anyone can share or explain why it can happen, because it uses the same key and IV when verifying the client finished message successfully. Are you using the same IV for each record? If so, see RFC 2246, page 20, last paragraph. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: signtool.exe
Nelson, Nelson B Bolyard wrote: Two years ago this week, John Smith wrote to us: When I sign using keytool.exe version 3.10 it signs OK, When I sign using keytool.exe version 3.11 it throws this error: using certificate directory: C:\Documents and Settings\myusername\Application Data\Mozilla\Firefox\Profiles\vsw8mp7m.default signtool: function failed: An I/O error occurred during security authorization. I have tried 3.10 with -X option and it works fine. 3.11 still gives the same error message. That's it. Works fine for me now. Just today I finally experienced this, and figured out the cause. The problem only occurs under a specific set of circumstances which are unusual for an NSS developer to ever encounter. However, they are the very circumstances in which a typical Solaris user uses signtool. It requires that NSS's shared libraries not be in the same directory where the signtool executable lives, nor in ../lib (relative to the directory where signtool lives) nor (evidently) in the LD_LIBRARY_PATH. These conditions are not true if you use freshly built NSS bits, or if you use NSS bits from the zip/tar distributions. They are true on Solaris, where the shared libraries live in /usr/lib/mps and the executable program files live in /usr/sfw/bin. There are several possible workarounds, all simple. Simply copy (don't symlink) the signtool executable into some directory of your choice, and copy or symlink the NSS shared libraries into that directory also. Then run the executable from that directory. The user above was using Windows, not Solaris. On Windows we didn't have freebl shared libs in 3.10, and thus no freebl library loading was necessary. The simplest workaround for Windows users is to set the PATH before running signtool. On other platforms, set the equivalent - LD_LIBRARY_PATH for Solaris/Linux, SHLIB_PATH for HP-UX, and LIBPATH for AIX. Doing this was already required on several architectures that already had freebl shared libs since NSS 3.2. It's just that in NSS 3.11 all platforms have freebl shared libs. The problem has been fixed once and for all in NSS 3.12 . signtool no longer loads freebl shared libs directly. It now uses the softoken shared library, like every other sane NSS program should, and the softoken loads the freebl shared libs properly. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: signtool.exe
Julien R Pierre - Sun Microsystems wrote, On 2008-11-12 14:46: The user above was using Windows, not Solaris. On Windows we didn't have freebl shared libs in 3.10, and thus no freebl library loading was necessary. That's true for Windows. The simplest workaround for Windows users is to set the PATH before running signtool. Beginning in NSS 3.11, loader always tries to load freebl using a full absolute path name. It tries several path names, but it doesn't try to load the simple shared library name. On Solaris, for example, when signtool is in /usr/sfw/bin, it tries to load these path names, in this order: /usr/sfw/bin/libfreebl_32int64_3.so /lib/libfreebl_32int64_3.so /usr/lib/libfreebl_32int64_3.so and then fails, because the desired library is actually /usr/lib/mps/libfreebl_32int64_3.so The reason it looks first in /usr/sfw/bin, rather than in /usr/lib/mps, is that it is statically linked, so the code that is normally inside of softoken, and normally returns the path name of softoken, lives in the signtool executable instead, and returns the path name of the executable itself, from which that initial directory name is obtained. On other platforms, set the equivalent - LD_LIBRARY_PATH for Solaris/Linux, SHLIB_PATH for HP-UX, and LIBPATH for AIX. Doing this was already required on several architectures that already had freebl shared libs since NSS 3.2. It's just that in NSS 3.11 all platforms have freebl shared libs. You'll recall that there is a requirement on Solaris that all programs run successfully even in the absence of LD_LIBRARY_PATH. The problem has been fixed once and for all in NSS 3.12 . signtool no longer loads freebl shared libs directly. It now uses the softoken shared library, like every other sane NSS program should, and the softoken loads the freebl shared libs properly. I agree that it's fixed in signtool. But that still leaves quite a few others that are still statically linked. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
