Julien R Pierre - Sun Microsystems wrote: > Nelson, > > Nelson Bolyard wrote: >> Julien R Pierre wrote on 2008-08-12 16:53 PDT: >>> Robert Relyea wrote: >>> >>>> SECMOD_OpenUserDB() will open new database slots in the internal >>>> database module. >>> Unfortunately, those additional DBs can't be manipulated separately. >> huh? >> - key gens can be done in each one separately, >> - certs can be imported into each or or exported from each one separately >> - certs can be found in each one separately, by tokenname:nickname > > Many of the NSS APIs don't take slot arguments and work on the union of > all the modules/slots configured. In particular mayn search functions > will look for certs and keys in all the tokens, ie. all the databases > available.
That was the other point I was trying to make about global state... It's common practice to set up services with private CAs, so that random nosy clients cannot connect to them. In an OpenLDAP proxy installation you'll have one server cert/key and arbitrarily many client cert/key pairs for connecting to various remote servers. Each of those client credentials may use different CAs, and may be different from the server's credentials. It would be bad if loading all of those certDBs meant that the proxy server would then accept incoming connections from clients using any of those CAs. Currently we can keep each context separate, using OpenSSL and/or GnuTLS. Likewise in the Mozilla Browser/nss_ldap situation, the credentials needed for LDAP authentication will probably be quite different from the credentials needed for web browsing or personal addressbook lookups. It would be extremely bad if simply using Mozilla on a system with nss_ldap/LDAP/MozNSS allowed arbitrary browser users to get privileged secure connections to their authentication server just by adding a new AddressBook definition. I've now gotten OpenLDAP libldap running with the PSM/NSS instance inside my Seamonkey browser, but it's only using the browser's already-configured databases at the moment. Getting the initialization right is looking to be more code than the rest of the libldap TLS framework. I think I'm going to stop here, until it starts to make more sense to me. >>> This is particularly a problem for trust. >> It does seem as though trust ought to be record in the same token as >> the cert by default, when the token is capable of recording trust. > > I am not certain where the trust will get recorded, and you may be > correct, but the trust that is read is the union of all the trusts from > each DB, by slot priority. > > When you call CERT_GetCertTrust you only get one trust object no matter > how many slots the cert may appear in, and whether the trust between > those DBs agrees or not. It's not possible to specify what slot you > would prefer the trust to come from. This was part of the trust domains > in the stan project which was not completed. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
