On 08/02/2011 09:51 PM, Robert Relyea wrote: > NSS has been facing these issues for a while now. After trying to get > something going in the PKCS #11 working group we finally implemented > this internally:
Yes, certainly. I evaluated that design while researching this topic. It's certainly a nice step forward, and as you said it works well for NSS. One way it falls short as a general purpose solution is the ability for packages (or other automatic scripts) to install configuration for PKCS#11 modules as separate files. When an automated installer or script has to modify a single file like pkcs11.txt, especially one that relies on single blank lines to separate blocks, things can get a bit fragile. But in any case, I just figured I'd bring it up and see what the interest is in such a standard flexible PKCS#11 config format, and if anyone wants to help review it, point out flaws etc... BTW, p11-kit tries to solve a several problems regarding use of PKCS#11 modules on the desktop (all documented [1] and explained). The nice thing about p11-kit is that it plugs into any PKCS#11 consumer without any modifications whatsoever [2]. So NSS can already use p11-kit, by loading the /usr/lib/p11-kit-proxy.so module. That module then loads the registered modules and exposes them to NSS. > NSS uses dynamically loaded modules to figure out what PKCS #11 modules > to load. The NSS softoken functions as one of these modules (as well as > a PKCS #11 module itself). libnsssysinit.so is one of these modules. The > idea here is libnsssysinit could be replaces by a module that gets the > PKCS #11 information from some other database. It could even do > complicated parsing stuff based on requesting application, user, and an > administrator's policy. This is cool. I'll have to look into this more. Thanks for pointing it out. Cheers, Stef -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
