Julien, It is rather David that tries to unify the NSS trust database. I agree with your comments regarding servers.
FWIW I'm working with a rather different project [1] which aims creating a system that can be used by *consumers* for existing tasks such as on-line banking. This project is technically closer to the Google Wallet [2] than NSS since NSS isn't capable of enrolling credentials on-line in an end-to-end-secured fashion. To succeed, "prehistoric" enrollment subsystems like Android's/Firefox's <keygen> are replaced by a 10-pass XML-protocol (KeyGen2). Talking about credential databases; The container part (SKS) supports logotypes (building on the established card metaphor), leaving distinguished names, key IDs, and SHA1 fingerprints for geeks to play with :-) The "humble" goal is that a set of core SKS primitives become an integral part of future CPUs. These primitives should fit nicely together with a Root-of-Trust system which anyway is required for secure boot. Another (still fairly immature) part, is adding an ACL-like facility to keys where entities also can be applications. This should work both in an "app"-world and for servers, reducing the need for littering servers with file-based key-stores. ACL's are the primary reason for making the key-store subsystem a service rather than a library. Cheers, Anders 1] http://webpki.org/auth-token-4-the-cloud.html 2] N/A. The core specification is covered by an NDA. On 2012-07-26 03:03, Julien Pierre wrote: > Anders. > > On 7/24/2012 23:33, Anders Rundgren wrote: >> Yes. It's an issue I'm actively trying to solve. NSS seems to have made >> some *attempt* at solving it... which has some issues, and which doesn't >> even seem to have been picked up by Mozilla's own products. > For the record, some Oracle server products such as Oracle Traffic > Director use the NSS shared database. > The main reason for doing so is in order for admin server to be able to > reliably edit the NSS cert/trust/keystore while the server is running. > It still uses application stores. Each server instance can have its own > store. The store is not per-user. > > It is questionable to me that the trust should actually be shared for > all applications running under the same user. Certainly in the case of > server apps you may only want specific CAs trusted for client auth for > example. If the trust is per-user, you would be forced to create new > users specifically for running those servers. This is sometimes the way > it's done, but not always. My same concerns would apply to private keys. > > I see the most value in unconditionally sharing strictly the public > data, ie. the CA and certs, between all processes and users. > But for trust and keys it really depends more on specific usage cases. > > It would sure be nice if Firefox and Thunderbird could share the DBs, > though. I don't believe they were the primary drivers of the NSS shared > database, just one one of them. > > Julien > -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
