On Fri, 2012-07-27 at 12:07 -0700, Robert Relyea wrote: > The news to me is that applications care, which means I need to > figure out an api to give the application that information.
The applications actively don't *want* to care, but the existing interface by which they use the shared system database is *making* them care, because they have to give the right dbpath to NSS_Init(). So rather than "give the application that information", making it possible for the application *not* to care would be much preferable. > If you are opening softoken from some other module, you presumable know=20 > the softoken "magic" to specify the database. softoken can be told to=20 > open more than one database from that string. OK, I'll play with that. Thanks for the pointer. > In short softoken can do it, but the normal PKCS #11 spec is silent on=20 > how to do this. Non-NSS users of softoken would have to learn the=20 > softoken protocol to use this feature. Yes, that much is clear. If we want to have a consistent set of trusted CAs across all applications¹ whether they use NSS, GnuTLS, OpenSSL or something else, our options are fairly much: 1. Try to build something based on Debian's update-ca-certificates which keeps an NSS database in sync with the flat PEM file. 2. Make everything else use the NSS databases. 3. Make NSS use some external databases. #1 doesn't provide any way for the user to have their *own* database, overlaid on top of the system one. And that would be something we'd have to implement from scratch in #3 too. The NSS databases exist, they work², and hence #2 seems to be the sanest avenue to pursue first. -- dwmw2 ¹ modulo the fact that CAs can be trusted for different purposes, of course. ² modulo my complaints about how hard it is to use them 'properly'.
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
