crypto consolidation status?

Robert Relyea rrelyea at
Fri May 8 18:09:04 UTC 2009

Adam Goode wrote:
> Hi,
> Some of my colleagues work on an RPC library that will be gaining TLS 
> support.
> Being familiar with
> 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 

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

I'll update that with library information as well.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3420 bytes
Desc: S/MIME Cryptographic Signature
URL: <>

More information about the fedora-devel-list mailing list