crypto consolidation status?

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

 



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? 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.

 * 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?

 * 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?

I know things are better with NSS 3.12. But it is not entirely clear how to write code to best take advantage of this and future enhancements, as the wiki claims. ("Conversion to NSS will automatically add these features to those applications that convert.")

It almost seems like a little more work is needed in NSS before it can really work as the one true crypto library.


Thanks,

Adam

--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux