[lsb-discuss] LSB conf call notes for 2008-04-23

[Jeff Licquia]

Attendees: Jeff Licquia, Jesper Thomschultz, Carlos Duclos, Darren
Davis, Stew Benedict, Juergen Doelle, Robert Schweikert, Marvin Heffler,
Vladimir Rubanov, Alexey Khoroshilov, Nelson Bolyard, Ted Tso, George
Wilson, Russ Herrold, Kay Tate, Jeff Johnson, Valerie Fenwick

Ed note: As always, the notes, being taken in a hurry, may contain 
inaccuracies, or clarifications may need to be made.  Everyone is 
encouraged to follow up to the list with those clarifications or 
corrections.

Welcome to our guests, who are here to discuss the OpenSSL/crypto situation.

Introductions.  Juergen: performance measurements on Linux; use 
encryption as part of that.  Crypto is painful; complicated to 
configure.  Most used libraries have lots of features used by few apps; 
most apps use only a few features.  Configuration can be different for 
each app.  Came into the call to see if these can be solved.

Nelson: work on NSS.  Can we give E-mail addresses?  Jeff: can contact
the lsb-discuss mailing list.

George: IBM LTC security team lead.  Talked with George Kraft about
crypto standardization.

Jeff: summary of basic problem.  Crypto (OpenSSL, specifically) is the 
#1 request from the LSB.  OpenSSL is the most popular, but has issues 
with API stability.  We need to solve this problem.

Ted: OpenSSL is an old API, has legacy issues.  Difficult to add new
functionality.  Data structures are exposed.  Not unique; Kerberos had
same problem.  Some ISVs ship wrapper libraries to provide an ABI they
can then trust.  Also, as a volunteer effort, not lots of time to fix
the problem.  Willing, though.  If some group would come up with an API,
they would likely accept it.

Nelson: NSS perceived as a latecomer, but was originally the Netscape
SSL implementation.  Originally developed as part of Netscape browser.
Delivers high-level crypto protocols; provides SSL/TLS and S/MIME for
Thunderbird.  AOL Instant Messenger also uses it.  Servers sold by Sun,
Red Hat use it.  Believe used by Google as well.  Development now done
by funded developers; Red Hat, Sun, Google.  Plus volunteer
contributions.

Nelson: Converted to shared libraries, overhauled ABI, after the
crypto export change in the USA.  Some stuff from pre-2000 has the same
issues as OpenSSL; newer APIs are better-designed.  New policy: never
change signature of exposed public function or exposed public struct.
Now at release 3.12; backward compatible back to 2001.  NSS people
involved in PKCS 11 API for hardware crypto acceleration.  No key
passing by value (handles only).

Nelson: NSS has been FIPS-evaluated four times, and certified.  About to 
do again this year.  PKCS 11 makes it easy to swap out pure software 
(NSS) with hardware.  NSS API acts as a middleware layer to PKCS 11.

Ted: on certification, OpenSSL was structured to maintain as long as
certain source files did not change and was built with certain
compilers.  Nelson: same thing can be done with NSS.  "Crypto boundary".
  FIPS evaluation is on the PKCS 11 module.

Nelson: can also do non-FIPS mode, less authentication.  Stress on key
hygiene; NSS does some good key management.

Ted: NSS seems to have the functionality people need.  How difficult to
port from OpenSSL?  There seems to be a shim lib for OpenSSL-to-NSS; how
well does it work?  Nelson: Red Hat started "crypto consolidation"
project to get all crypto products to use NSS, with unified key
management, config, etc.  They have "mod_nss" for Apache, generic shim
layer (not sure how complete).  Apache was a big user of SSL.

Ted: in our analysis, lots of open source apps use OpenSSL; how do we 
get them ported?  Jeff: how difficult to do a straight port?  Nelson: 
depends on usage and goal.  Part of Red Hat goal is to use same key 
store as well; this requires more work.  Ted: use of user certs? 
Nelson: common cert store is also important.  Ted: solution for porting 
of apps may be sufficient.  Nelson: several layers apps can use, from 
raw crypto algorithms to PKCS 11 to PKCS-independent to high level 
layer.  Typical app wanting to do, say, IMAP SSL, should use the high layer.

Robert: documentation, and availability?  Nelson: NSS is the crypto
layer for all Mozilla products.  Most distros ship NSS as a separate
package.  Docs are a weak point.  All docs are on the Mozilla web site;
wiki, and doc section.  Ted: PKCS 11 is well documented; NSS docs not
quite to the level of a standards document?  Nelson: yes, some of the
API is still undocumented.  Open source has made us lazy.  Robert: we
would need good docs to include in the LSB.  Nelson: definite interest
in becoming part of the LSB.

Ted: possible to get a paid tech writer to flesh out the docs?  Nelson: 
not great hope for hiring, but the developers would be interested in 
being available.  Not lots of spare development effort.  Ted: would only 
create a spec for the subset most useful to apps.  How many interfaces, 
if we do the work?  Nelson: not sure.  Well-defined public interface; 
should be able to look at the list.  SSL library is best documented. 
Ted: could start with PKCS 11 and SSL library.

Wrap-up.  Lots to talk about; everyone is interested in continuing the
conversation.  Will try for next week.  Guests are asked to send their
availability to Jeff, and also to ask for personally-mailed copies of 
the minutes.