Adam Goode wrote:
Hi,
Some of my colleagues work on an RPC library that will be gaining TLS
support.
http://minirpc.cs.cmu.edu/
Being familiar with
http://fedoraproject.org/wiki/FedoraCryptoConsolidation
I of course told them that NSS was the best library to use for this.
But there are a few issues with this:
* What is the rationale for requiring a shared certificate
store?
The main rational is to put the trust control back in the hands of the
user and the administrators.
More importantly, we would like to allow an application to
temporarily use a private cert (that it may trust for some reason)
without spreading that trust to all applications on the system.
It seems like the issue of certificate management is separable
from the actual crypto part.
In NSS trust is handled in terms of types. That is
a certificate is
trusted for SSL or S/MIME or Code Signing. It's possible for an
application to trust additional certs which aren't in the normal NSS
database temporarily (Firefox uses this when you accept an override, for
instance).
Applications are also allowed to open multiple private databases as
well, though this feature is seldom used at the current time.
Note that many of these types of actions on the part of the application
makes it more difficult to centrally manage crypto on your machine. So
while they are available to you as an application, I suggest making it
configurable to turn these options off so that admins can still control
the security options on a box.
* We are trying to use TLS from a library. The NSS documentation seems
to suggest that calling NSS_Init more than once is bad. It doesn't
look like it would be safe to call NSS_Init from a library. Really
NSS should be returning a context object that encapsulates all NSS
state, yes?
There is an internal state for NSS called a trust domain. This trust
domain is not yet surfaced, mainly because the use case for running
multiple separate trust domains in a single application has never truly
surfaced. With a single view of the trusted certs per user, it still
does not come into full view.
There are is the issue of the first NSS_Init wins that Rob pointed out.
I'm hoping to fix that issue in the next month or two and send out
recommendations on how libraries should initialize NSS.
* It's not obvious what to pass to NSS_Init. Looking at nss_compat_ossl
shows some tricks with getenv("SSL_DIR") and such. Is that practice
documented anywhere?
We're trying to converge on a single rule for all
applications. You can
find that here
https://wiki.mozilla.org/NSS_Shared_DB_And_LINUX
I'll update that with library information as well.
bob