someone else complaining about Mozilla SSL policy
http://www.cs.uml.edu/~ntuck/mozilla/ I think we covered this before and he misses the fact that there are free alternatives out there like StartSSL that I use (Thanks Eddy!). Dave 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: someone else complaining about Mozilla SSL policy
On 11/03/2008 03:40 PM, David Stutzman: http://www.cs.uml.edu/~ntuck/mozilla/ I think we covered this before and he misses the fact that there are free alternatives out there like StartSSL that I use (Thanks Eddy!). You are welcome, Dave! Even though we receive a lot of credit and many encouraging and thankful email messages, it doesn't happen so often publicly. Thanks for that. Indeed this subject has been covered extensively in blogs and at Bugzilla; it's hard to convince somebody otherwise who doesn't see the value in the vetting by a third party. Not much to do here...except point to https://bugzilla.mozilla.org/show_bug.cgi?id=460374 PS. How about using your StartSSL client certificate for your email (I suppose you received one during registration)? :-) -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Ping - ping...
On 10/29/2008 11:13 PM, Eddy Nigg: Frank, what happened to the schedule and inclusions of CAs? Is there any problem preventing us from continuing to process the CAs which are ready for the comments period? BTW, I'd like to propose to cut the comments period to one week, with one additional week optional, should some issue has been raised during the first week. Should no issue have come up during the first week, the CA inclusion should proceed according and depending to schedule. Of course should there be a problem with this proposal we could always review it once again. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: someone else complaining about Mozilla SSL policy
Honestly? The concept of vetting by a third party really doesn't mean anything to those who choose to deal with things themselves, and it especially doesn't mean anything to those who believe that the fundamental concept of X.509 certificates, as applied by the people who developed the SSL protocol, is fundamentally fucked up. I don't need to pay a third party to have a random conversation with someone on the street. I don't need to pay a third party to give a flyer to anyone I meet on the street. I don't need to rely on a third-party vetting process to have a random conversation with someone on the street. I don't even need to ask for a government-issued ID to have a random conversation with someone on the street. And you know what? I DON'T WANT TO. I don't want to do this on the web, either. I don't care if you or anyone else thinks that this makes it better for the drooling computer and security-illiterate masses, I choose not to. I don't get that security dialog if I communicate via plain-text (non-https); if I happen to want to have a private conversation with the same person (the same site and IP), why the hell do I need a third party to step in and say it's dangerous if you don't have something that I'VE VETTED (or worse, it's insanely dangerous if you don't have something that WE'VE VETTED? It's arguably less dangerous to do unauthenticated TLS than non-encrypted web browsing, but the dialog as it's currently implemented arguably destroys any faith in the ability of the computer system to be a tool that we use, rather than a paradigm that controls us. It destroys our ability to trust. And you know what, that's the business that CAs are in, either giving away limited amounts of trust or selling the same. CAs have entirely too much power under the currently dominant paradigm -- they can choose to embed or withhold any X.509v3 extension that they want in the certificates that they issue, and the person they issue them to has absolutely no say in the matter. A web certificate, which (at least from GoDaddy and others) includes both network client and network server extensions, can be used in either capacity -- but it can't be used to sign software packages that people can choose to trust, it can't be used to sign PDF documents, it can't be used for email authentication, it can't be used for anything that isn't explicitly embedded into the certificate by the CA. Get another browser, then! Build your own from the Mozilla sources! Just don't call it Firefox! I can hear the cries. Unfortunately, it's just not that simple. Do YOU want to have to open up another browser, another piece of software to clutter up your taskbar and desktop, just to be able to communicate the same fucking protocol as Firefox? I sure as hell don't. But more importantly, /I also don't want to have to support people who want to have a private conversation with me to the point of having to tell them to download and install another piece of software on their computers just to enable a conversation/. I'm already having major problems trying to find a single piece of software that works for instant messaging and video chats and audio chats. Your argument doesn't hold water, Eddy. It's the same argument that Nelson and others (the entire security team) seem to use to justify their interference in everyone's conversations and interactions, their assumption of fiduciary duties without consent from the people who use their software. Firefox 2 had an easier-to-navigate security dialog than Firefox 3 (at least 'accept this certificate temporarily for this session' took only one click instead of 4, and all of its information was in a single dialog box). I'm sick of having to deal with this shit. And you know what? The reason why X.509 is completely fucked up the way it's currently implemented has to do with the trust boundaries in place, the insistance that CAs have on implementing their policies. That's perfectly fine, as long as it doesn't impact me, or come into conflict with my policies, or the policies of those I interact with -- but it does. I have a need to segregate various groups of colleagues and friends and associates that I have, just to make my life a bit easier. I'm not going to give you all the entire list of nicknames that I have, or when I used them, just to prove a point -- I will just state that I have several nicknames, several handles, several groups of people I interact with that I have reason to not know about each other. I'm not perpetrating fraud, I'm not doing anything illegal -- I'm just ensuring that my right to free expression doesn't bleed through to cause me problems with (for example) employment. (Would a bank hire a manager who wrote erotic fiction in his or her spare time? Probably not, if the bank knew about it. And the bank would probably fire said manager if they found out.) As a matter of information security, there are several aspects of this: 1) How do I know that any
Re: someone else complaining about Mozilla SSL policy
On 3 Nov., 14:40, David Stutzman [EMAIL PROTECTED] wrote: I think we covered this before and he misses the fact that there are free alternatives out there like StartSSL that I use (Thanks Eddy!). This would only be true if the StartCom root would be included in Firefox 2, Windows, MacOS and Opera. At least in Windows its not included; StartCom is apparently not part of Microsofts root certificate program: http://support.microsoft.com/kb/931125 Or am I missing something, Eddy? Sorry, but its a little bit unfair to point people to StartSSL when they experience the Firefox SSL UI blues. They will get complaints from all those other browser users after they happily installed the free StartSSL certificate on their server. Its just bad advice, given with some big Mozilla blinder. Even Firefox 2 users are left out. Nothing against StartCom, but its prominent role in the Firefox SSL UI discussion doesn't seem justified. jh ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: someone else complaining about Mozilla SSL policy
On 11/03/2008 08:46 PM, [EMAIL PROTECTED]: On 3 Nov., 14:40, David Stutzman[EMAIL PROTECTED] wrote: I think we covered this before and he misses the fact that there are free alternatives out there like StartSSL that I use (Thanks Eddy!). This would only be true if the StartCom root would be included in Firefox 2, Windows, MacOS and Opera. At least in Windows its not included; StartCom is apparently not part of Microsofts root certificate program: http://support.microsoft.com/kb/931125 Or am I missing something, Eddy? As of now this is correct. The StartCom root is shipped and included with Firefox (since some version of 1.5 upwards and not as you indicated below) and with Apple OS X (since 10.4 (Tiger)). Concerning Microsoft all I can say at this point is, that we are working on it. I really except, that once this happens, it will make self-signed certificate completly obsolete, except for a few cases like routers. Sorry, but its a little bit unfair to point people to StartSSL when they experience the Firefox SSL UI blues. They will get complaints from all those other browser users after they happily installed the free StartSSL certificate on their server. Its just bad advice, given with some big Mozilla blinder. Even Firefox 2 users are left out. First of all I don't know what your problem is with FF2, but feel free to contact me and I'll be glad to look into eventual problems. Many times incomplete installation at the server are cause for errors. Secondly, lets get real here! If you are using a self-signed certificate you'll get errors and warnings with *ALL* browsers - and so does any visitor to such a site. Now, by using a certificate by a third party - even if it's one from StartCom - your site is *NOT* using a self-signed certificate, not subject to a potential MITM attack and depending on your typical user base and product they are using, your site will *NOT* issue any errors. For European countries like Germany, the Scandinavians but also others, this is more than 50% (if you combine Apple Safari and Firefox market share). It certainly makes a lot of sense for Firefox, since this is the product Mozilla cares about. But I'm sure you followed better advice and you use certificates from a CA with better coverage... -- 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
nss-3.10 with smartcard on obfuscated class files.
1. I insert my hardware token with smartcard certificate into my DataKey reader. 2. I move each jar file, one at a time, to my X drive, xyz folder. 3. I log into UNIX and extract the jar with the jar tool (jar -xf file.jar). 4. I then open a DOS window and issue the signtool command (signtool - d . -k DataKey:Certificate -p password -Z outfile.jar X: \xyz). At this point, signtool changes the name of obfusicated files (g.class -- g~2.cla) because Windows does not accept two similarly named files located in the same folder. The jar file has obfuscated classes like: G.class g.class Any suggestions on how to get signtool and windows to play nicely with these files? Thanks ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: CERTCertDBHandles and OCSP
On Nov 3, 3:16 am, Nelson B Bolyard [EMAIL PROTECTED] wrote: [...] Just call the function that returns the handle of the default trust domain. You won't regret it. /Nelson Hi Nelson, Thanks. I now understand. Cheers, Antonio ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: nss-3.10 with smartcard on obfuscated class files.
[EMAIL PROTECTED] wrote, On 2008-11-03 14:10: 1. I insert my hardware token with smartcard certificate into my DataKey reader. 2. I move each jar file, one at a time, to my X drive, xyz folder. What kind of drive is that? USB stick? local hard drive? network file system of some sort? (NFS, CIFS, etc.) What windows file system semantics does it support? Is it FAT32? NTFS? other? 3. I log into UNIX and extract the jar with the jar tool (jar -xf file.jar). 4. I then open a DOS window and issue the signtool command (signtool - d . -k DataKey:Certificate -p password -Z outfile.jar X: \xyz). At this point, signtool changes the name of obfusicated files (g.class -- g~2.cla) because Windows does not accept two similarly named files located in the same folder. Years ago, I had a Windows PC running Win2K with the Hummingbird PC NFS client in it. On that PC, I could mount NFS file systems directly as logical drives. On an NFS-mounted logical drive (served on a Unix system), in any given single directory, with my Windows PC I could easily create multiple files and subdirectories whose names differed only in the capitalization of certain letters. E.g. I could have fun, Fun, fUn, etc. and Windows happily kept them all separate and didn't confuse them, and didn't attempt to change them. Based on that experience, I gather that it is possible to create a file system for which Windows will not make any of its usual file name transformations. But with either the NTFS or FAT32 file systems, Windows will not allow two files in the same directory to have names that differ only in capitalization of letters. Samba servers typically appear to have NTFS file system semantics. The jar file has obfuscated classes like: G.class g.class I think that's hopeless on Windows, unless you have one of those very rare file systems for which Windows allows file names to differ only in capitalization of letters. Any suggestions on how to get signtool and windows to play nicely with these files? I gather that you're attempting to do the signing on a Windows system because your private key is on a smart card that works with Windows but does not work with your brand of Unix. You could try Linux. Linux has pretty good support for some smart card readers. If you got your smart card to work on Linux, then You could do all the steps of signing the JAR on that system. But I fear the result is still likely to be unsatisfactory on a Windows system. Even when successfully signed, any attempt to unzip the contents of that JAR onto an NTFS or FAT32 file system on a windows system will run into the same problem with file name conflicts. (You know that JAR files are ZIP files, right?) I think you're ultimately going to need to find a way to have file names that differ by more than the capitalization of letters. Then you shouldn't have any problems, I think. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: someone else complaining about Mozilla SSL policy
On 11/03/2008 08:46 PM, Kyle Hamilton: Honestly? The concept of vetting by a third party really doesn't mean anything to those who choose to deal with things themselves Because they don't understand the concept. Period. I don't need to pay a third party to have a random conversation with someone on the street. Right! Because you most likely don't yell your passwords of your blog, forums or secure codes of your cash card on the street randomly. If you don't have something to say, don't secure... I don't need to pay a third party to give a flyer to anyone I meet on the street. Certainly, besides that you don't have to pay either. The issue isn't about payment, it's about depending on somebody else. However the concept of CAs is beyond the openssl command. I don't need to rely on a third-party vetting process to have a random conversation with someone on the street. Yes! Nobody asked you to secure your unimportant chatters... I don't even need to ask for a government-issued ID to have a random conversation with someone on the street. And you know what? I DON'T WANT TO. YOU DON'T HAVE TO! Besides that you recognize somebody on the street - and you very quickly make an assessment if and how much you want to trust that person you just met on the street. Somebody may have or earn your trust even on the street! You can't do that the same way on the Internet. But neither do you have to trust just about anybody on the Internet either...or are you publishing your passwords, bank account numbers etc. on your web site? You don't and neither you would tell it somebody on the street. I don't want to do this on the web, either. I don't care if you or anyone else thinks that this makes it better for the drooling computer and security-illiterate masses, I choose not to. Kyle, this is perfectly fine with anybody here at Mozilla and elsewhere! You don't have to secure your web sites, not your email messages, nothing! I don't get that security dialog if I communicate via plain-text (non-https); if I happen to want to have a private conversation with the same person (the same site and IP), why the hell do I need a third party to step in and say it's dangerous if you don't have something that I'VE VETTED (or worse, it's insanely dangerous if you don't have something that WE'VE VETTED?) Of course here we've got the conflict. Why don't you stay with plain text? If you think that something needs to be secured, than do it the right way. Otherwise why secure it in first place? How shall _I_ know that I'm talking to _YOUR_ web site? And if I don't know for certain that this _IS_ your web site, why secure it in first place. All the rest is simply security theater as Nelson used to say... It's arguably less dangerous to do unauthenticated TLS than non-encrypted web browsing, Kyle, what nonsense are you talking about. Encryption through a MITM is the same as no encryption at all. Worse, it gives you a sense of security and privacy when in fact there is none. but the dialog as it's currently implemented arguably destroys any faith in the ability of the computer system to be a tool that we use, rather than a paradigm that controls us. It destroys our ability to trust. Why? Did the computer system lie to you? And you know what, that's the business that CAs are in, either giving away limited amounts of trust or selling the same. CAs have entirely too much power under the currently dominant paradigm -- they can choose to embed or withhold any X.509v3 extension that they want in the certificates that they issue, and the person they issue them to has absolutely no say in the matter. Why? Do you want to have CA:TRUE in your certs? Or perhaps e-mail protection, even though the email wasn't validated? A web certificate, which (at least from GoDaddy and others) includes both network client and network server extensions, can be used in either capacity -- but it can't be used to sign software packages that people can choose to trust, it can't be used to sign PDF documents, it can't be used for email authentication, it can't be used for anything that isn't explicitly embedded into the certificate by the CA. Fantastic! That means that the folks at GoDaddy do their job right! Get a code signing certificate for code signing - which has different requirements than web servers and most likely can't be had for twenty bucks, because it requires identity or organization validation. Get another browser, then! Build your own from the Mozilla sources! Just don't call it Firefox! Feel free - it's open source... I can hear the cries. Unfortunately, it's just not that simple. A, so there is somewhat more into building a browser and making it popular than the code... Do YOU want to have to open up another browser, another piece of software to clutter up your taskbar and desktop, just to be able to communicate the same fucking protocol as Firefox? I sure as
why nss has very little doc about usage of api
hi all: when i use nss to develop some cipher program(just for local, not internet), i.e. just perform miscellaneous cryptographic operations, the only reference i can use is the example code from MDC. when i want a detail parameter explanation, what i got is just this function's MXR source. I used google to search, but nothing useful got. can anyone give me some hints about more API doc? thanks in advance ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
