[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: crypto consolidation status?



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

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]