Howard Chu wrote, On 2008-08-10 03:30: >> Nelson B Bolyard wrote: >>> Someone could write a PKCS#11 module that uses PEM files as its storage. >>> It wouldn't be FIPS validated, at least not initially. > > In that case, there's even less motivation to adopt NSS, since OpenSSL is > moving ahead with validation
Assuming you mean FIPS validation, NSS has been FIPS validated 4 times already, and I expect it will start a 5th validation this year for the latest version, NSS 3.12.x. > Following on from the discussion in > https://bugzilla.mozilla.org/show_bug.cgi?id=292127 today I took a look > at what would be involved in adding NSS support to OpenLDAP. Aside from > the lack of hassle-free PEM support (which it appears may not be a > problem for much longer) When one considers all the important reasons to choose a crypto implementation, support for one file format which is not used in any standard protocols (e.g. TLS, SMIME) doesn't seem like a biggie. All the makers of different crypto libraries each had their own separate ways of storing private keys at one time (and still do). They agreed about 10 years ago to adopt PKCS#12 as the one common format for interchange of private keys, and today they all offer tools for making and using PKCS12 files. > the other obvious source of pain is the lack of an intuitive API for > selecting cipher suites. Huh? What's unintuitive about these? SSL_CipherPrefSet(PRFileDesc *fd, PRInt32 cipher, PRBool enabled); SSL_CipherPrefGet(PRFileDesc *fd, PRInt32 cipher, PRBool *enabled); SSL_CipherPrefSetDefault(PRInt32 cipher, PRBool enabled); SSL_CipherPrefGetDefault(PRInt32 cipher, PRBool *enabled); Further, the function SSL_GetCipherSuiteInfo(PRUint16 cipherSuite, SSLCipherSuiteInfo *info, PRUintn len); outputs a structure of info about any supported cipher suite, making it easy to construct a localized GUI for the user tho choose from among the offered cipher suites, and have that GUI grow automatically with new NSS releases, without having to recode the application. It eliminates or reduces application dependencies on hard coded tables of information about cipher suites. > The notion of NSS_SetDomesticPolicy / NSS_SetExportPolicy / > NSS_SetFrancePolicy is quaint at best. It's a relic of a closed-source > legacy that makes no sense in FOSS that can be freely used anywhere in > the world. There are still countries in which it is a crime to use certain forms of encryption, open source or not. Those functions (and more that you didn't mention, such as SECStatus SSL_CipherPolicySet(PRInt32 cipher, PRInt32 policy); SECStatus SSL_CipherPolicyGet(PRInt32 cipher, PRInt32 *policy); ) continue to be useful for people making products for use in those countries, making it possible to implement arbitrary national policies, of which the 3 functions you mentioned are examples. > While there appears to be a function for enumerating the available cipher > suites and their names, it would also be convenient to have a function that > returns the cipher number for a given name, to make it easier to work with > settings read from a configuration file. And I suppose you would want such a function to use OpenSSL's non-standard name strings for that, right? BTW, Are you aware of the Linux Foundation's "Linux Standard Base" (LSB) effort? http://www.linuxfoundation.org/en/LSB One of the primary considerations for acceptance into the LSB is binary backwards compatibility assurances from the libraries. NSS is being considered for the LSB as a/the standard library and interface for SSL, in large part because NSS has been offering shared libs with a strong guarantee of API and ABI backward compatibility ever since NSS was first released as shared libraries in 2001 (or 2002, I forget). If you absolutely must have every thing work exactly like OpenSSL to be happy, then use OpenSSL. Complaints about NSS, that it isn't exactly like OpenSSL aren't going to motivate NSS to change much. Absent cryptographic functionality is one thing. Absent emulation of OpenSSL is quite another. Near the beginning of this thread, I asked for people to report absent crypto functionality. But so far, what I've heard is: "It isn't OpenSSL", which is not a statement about cryptographic functionality. _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
