Kyle Hamilton wrote, On 2008-07-28 17:23: > This is, honestly, a matter of "NSS's implementors decided to force > administrators and users to jump through hoops." There may be > legitimate policy concerns with certain policies that require > everything to be inside the database that NSS uses.
Nothing requires that. The requirement is that the certs and keys be in PKCS#11 modules. NSS's own PKCS#11 modules are but a few out of hundreds. (Well, tens, at least :). > .. but for those who don't have those policy restrictions, it could be > called "inelegant". The requirement to put all cryptographically sensitive information into a well defined crypto boundary seems very elegant. It explains how NSS was able to work with so many third party crypto gizmos starting in the late 90's, and how it was able to get 4 FIPS 140 certifications. I certainly wouldn't call files containing RSA private keys in bare PKCS#8 files even remotely elegant, or safe. > Which revision of PKCS#11 was NSS support written to? I'm seeing that > the latest available from RSA Labs is v2.20 amendment 3. NSS will work with any module that is v2.x, I believe. NSS's own PKCS#11 module claims to be 2.10 (don't know why, because it has many features from 2.20). There is a PKCS#11 module that uses Windows' key and cert stores as its stores, although it is unsupported. One could write a PKCS#11 module that uses PEM files in some directory as its store, and if done well, NSS would very likely work with it. But I have no incentive to write such a thing. Please feel free. _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
