NSS for PKINIT, in-progress patches available, feedback sought

[Nalin Dahyabhai]

On Sat, Oct 08, 2011 at 05:15:59PM -0400, Greg Hudson wrote:
> I built nss-3.12.11 and nspr 4.8.9 from source, built krb5 against it
> (thanks for keeping this rebased against my recent preauth interface
> work), and ran through the test suite.  I ran into the following
> problem:
> 
> In crypto_get_pem_slot(), you call SECMOD_LoadUserModule with the module
> spec "library=libnsspem.so".  There are several problems here.
> 
> 1. Most importantly, if the module fails to load, SECMOD_LoadUserModule
> still returns a module with a non-null function table, and then
> SECMOD_UpdateSlotList crashes trying to access through the table.  I'm
> not sure if this is an NSS bug or a caller bug.  The control flow is
> that SECMOD_LoadModule calls secmod_LoadPKCS11Module to try to load the
> library, gets an error return, goes to the "loser" label, and returns
> the unloaded module.

You're right, that doesn't seem to jive with the docs on the web site at
https://developer.mozilla.org/en/NSS_PKCS11_Functions#SECMOD_LoadUserModule

It appears that we can double-check by consulting the 'loaded' field in
the returned structure.  I've opened a bug in the local bugzilla to run
it by our local NSS people to see if there's a doc problem or if it's
something we're expected to be checking for, and updated the module to
check for both a NULL result and a non-NULL result with loaded==FALSE.
If it turns out that it's a bug in NSS, no harm done.

> 2. libnsspem appears to be a Fedora special; that is, it doesn't appear
> to exist in any Debian packages, googling for it finds only
> Fedora-related links, there's no obvious project page for it, and it's
> coded as a Mozilla source addon to be dumped in by the Fedora NSS SRPM.
> I guess NSS is incapable of reading PEM files without this addon.  Since
> our pkinit testing code uses PEM files, this seems to render the PKINIT
> support untestable except on Fedora or RHEL (and also renders most of
> our documentation of PKINIT valid on Fedora or RHEL, although it may be
> possible to use PKINIT without PEM files).

Hmm, I should have remembered and noted that.  It's being tracked
upstream at https://bugzilla.mozilla.org/show_bug.cgi?id=402712, but
it's taking a while.

The PEM module's used for loading FILE: and DIR: identity types, but
handling for PKCS11:, PKCS12:, and NSS: identities doesn't depend on it,
so they should still work.  The CRL caching code also doesn't go through
the module.

> 3. Loading the module like this means that libnsspem.so needs to be
> installed in the runtime linker path, unlike every other krb5 dependency
> I'm aware of.

The Fedora packaging puts the module in $libdir along with the soft
token (libsoftokn3) and the built-in roots (libnssckbi), so I'd expect
(well, hope for, more like) libnsspem to land there as well.  

> 4. The name libnsspem.so is ELF-specific.

I've added an attempt at guessing (replacing the .so suffix with the
value of $(DYNOBJEXT) set at compile-time, and dropping the "lib" prefix
on Windows), but it'll probably have to be revisited since we end up
passing the name to NSS's module loader, and that combination's not easy
for me to test on anything other than Linux.

> I guess none of these are real blockers if (1) should be treated as an
> NSS bug, but they all seem unfortunate.

Hopefully this update will get you past this hurdle.

Thanks again,

Nalin