Re: netscape certificate extensions
Nelson B wrote: Jean-Marc Desperrier wrote: In my tests, Communicator 4.x did not enforce the restriction you describe in all case. If the intermediate/root CA certs had no netscape cert type extension at all, it was possible to enable then for object signing without problems, despite a description implying they were required to explicitly have it. Very interesting. That would be a pretty serious flaw, and would (I think) weaken the relative strength of the Object Signing OID (as compared to the Code Signing OID). I don't get how it weakens the Object Signing OID with regards to Code Signing OID. It's the same behaviour as Code Signing OID where only the signing cert requires the OID. In fact, everything is similar to Microsoft implementation of Object Signing where one can too use the extended key usage to restricts the ability of the CA to emit or not Object Signing certs, even if this kind of use is not endorsed by pkix (I asked them when I was actually interested in this and did the above test, and the consensus was eku should apply to the cert, and not be herited when used for a CA cert, and if this kind of CA restriction was really useful then a new key usage would be better than diverting eku from it's original intend). ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: netscape certificate extensions
Jean-Marc Desperrier wrote: Nelson B wrote: Jean-Marc Desperrier wrote: In my tests, Communicator 4.x did not enforce the restriction you describe in all case. If the intermediate/root CA certs had no netscape cert type extension at all, it was possible to enable then for object signing without problems, despite a description implying they were required to explicitly have it. Very interesting. That would be a pretty serious flaw, and would (I think) weaken the relative strength of the Object Signing OID (as compared to the Code Signing OID). I don't get how it weakens the Object Signing OID with regards to Code Signing OID. It's the same behaviour as Code Signing OID where only the signing cert requires the OID. It may be that, but that is not how it was designed to be. The design/intent was to require the EE cert and all intermediate CA certs to have this extension/OID, and for the root to be trusted for Object signing, in order for the EE cert to have object signing permission. In fact, everything is similar to Microsoft implementation of Object Signing where one can too use the extended key usage to restricts the ability of the CA to emit or not Object Signing certs, even if this kind of use is not endorsed by pkix (I asked them when I was actually interested in this and did the above test, and the consensus was eku should apply to the cert, and not be herited when used for a CA cert, and if this kind of CA restriction was really useful then a new key usage would be better than diverting eku from it's original intend). I'm not suggesting the design for netscape object signing was perfect, merely stating what the design intent was. -- Nelson B ___ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
Re: Does selfserv have a memory leak?
Cesard, Patrick O. wrote: The -2 filename option on the command line of selfserv: What use case is the fdx connection addressing? It looks like it's dealing with reading and writing a big file? As you know, SSL is very commonly used with HTTP, and HTTP is a half-duplex (HDX, two way alternate) protocol. But the SSL protocol itself is not limited to being used only with half-duplex appliction protocols. SSL will also work with full-duplex (FDX, two way simultaneous) application protocols. Selfserv and strsclnt are intended to be able to test FDX as well as HDX use of SSL. When testing HDX (the default), strsclnt and selfserv act as https client and server. When testing FDX, they merely send each other file content simultaneously. Also, any idea why the function handle_fdx_connection() is not used? I don't know. Here is some speculation. Our QA test scripts do not test the FDX mode of operation, and it is not frequently used. It is possible that the FDX code has experienced bit rot, meaning that some source code modification has had the unintended side effect of disabling FDX code. -- Nelson B ___ 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
