Rich, Rich Megginson wrote:
I've been looking at the problem of different libraries/different clients each with their own private key/cert db in a single process (for example, the Thunderbird ldap/nss_ldap problem). In this case, the user may want nss_ldap to keep its certs and keys (including ca certs) separate from those used by Thunderbird. I think it could work by first creating a token based on a unique key (e.g. to use the openldap config directives, a unique combination of cacertfile, cacertdir, certfile, and keyfile). Then call SECMOD_OpenUserDB() to create a private db based on that token, and import CA certs into this db (from pem files, for example). This function returns a PK11SlotInfo * - how do you get a CERTCertDBHandle * given that slot pointer? If I get this, I think I can use this to import certs, use for various VerifyCert functions, and even pass to SSL_CertDBHandleSet to use this cert DB for SSL.
What you want to do would require a planned feature of NSS 4.0 called "multiple trust domains". This would allow you to create different CERTCertDBHandle* made of a different list of slots/modules/tokens.
The default trust domain in NSS 3.x is the union of all the modules/slots/tokens available. That means you will find every object including some you don't expect. This is not generally a big problem for verification unless there is overlap (duplicated issuer and serial number). However, the PKIX verification algorithm also requires trust information. This is where it gets tricky. You would presumably want to use different trust info, from your separate LDAP cert DB. But with the default unique trust domain, there is only a single set of trust information.
Unfortunately, the work to enable multiple trust domains has been delayed indefinitely.
-- dev-tech-crypto mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-crypto
