On Tue, 2015-05-12 at 10:17 -0700, Ryan Sleevi wrote: > On Tue, May 12, 2015 9:44 am, Peter Bowen wrote: > > How about an even simpler solution? Don't have p11-kit load the > > PKCS#11 modules, just provide a list of paths and let the application > > pass those to NSS. That way the application can choose to > > transparently load modules without user interaction, offer a UI option > > for "load system modules", or provide a pick list of module to load. > > Right, that's known as an NSS Module DB (and is in fact what the > pkcs11.txt parser is) > > The shared library reports back the supported modules and configuration > flags, and then NSS loads and initializes them as if they were first-class > modules. > > http://mxr.mozilla.org/nss/source/lib/sysinit/nsssysinit.c is an example > of this. > > [Yes, it relies on a non-standard extension to PKCS#11's C_Initialize; caveat > emptor]
I think it's actually an extra entry point 'NSS_ReturnModuleSpecData'
in the module, isn't it? Or am I thinking of something different?
Either way, I think we could certainly implement a module which does
this instead of doing what p11-kit-proxy.so does. Such a module
doesn't need to provide a C_GetFunctionList at all; it would *just*
provide a Module DB.
However, that doesn't really address the problem of *how* we get NSS
to load the module in question by default. We still have a chicken-and
-egg problem with loading it.
(There's also a tangential discussion to be had here about whether
it's best to load modules in NSS as 'first-class modules', or
whether to do it through p11-kit{,-proxy}. The issue is as
follows:
Some applications end up loading more than one crypto library at a
time — they use different plugins or higher-level protocol
libraries, each of which might have been built against a different
underlying crypto library. And once we start to see all crypto
libraries consistently loading the same set of PKCS#11 tokens
according to the policy, we need to care about what happens when
a given PKCS#11 module is loaded more than once into the process.
See http://p11-glue.freedesktop.org/doc/p11-kit/sharing.html
In the short term, I suspect that loading p11-kit-proxy might be
the better option. However, in the longer term perhaps we want
to be loading modules into NSS in a manner which is compatible
with the p11-kit 'sharing' mechanism. And then it would indeed
be nicer to load the p11-kit configured modules as 'first-class'
modules.)
And just to follow up another slight tangent on the separate
requirement to identify objects by a RFC7512 PKCS#11 URI... Ryan, in
bug 1162897 you said you don't want NSS to parse those for itself, and
that it should use a separate library. That functionality is also
provided by p11-kit.
So *maybe* the best option when all is considered is just to bite the
bullet and start using p11-kit directly from NSS. Which raises more
questions... do you make it optional? The RFC7512 parsing would then
be absent from NSS when built without p11-kit, so what form of failure
mode and fallback would you have? And how ugly would it be to
*conditionally* use the p11-kit wrappers for managing multiple PKCS#11
consumers?
But back to the point about how we get NSS to load the appropriate
module(s) by default...
Ideally, I think this should Just Work. I don't think we want to have
to do a bombing run on all NSS-using applications and modify them
individually. But if we *were* going to do that kind of thing, then I
think we might as well just fix them all to use the Shared System
Database. rather than anything new. Does that seem like a reasonable
assertion? Then the distributions can just add p11-kit-proxy.so to
their /etc/pki/nssdb/pkcs11.txt and we're done.
If we *did* want to make apps consistently use the Shared System DB,
we'd want a simple way for applications to *know* whether they should
use sql:/etc/pki/nssdb or $HOME/.pki/nssdb. Currently there is no
coherent answer to that, that I'm aware of. I *really* don't want to
end up adding the the open-coded version from
https://bugzilla.mozilla.org/show_bug.cgi?id=490238#c37 to a whole
bunch of individual applications!
If we want to do it *without* having to modify all applications — and
I think we do — then perhaps the best place for it is the softokn's
Module DB implementation. So either in NSC_ModuleDBFunc() or the
NSSUTIL_DoModuleDBFunction() that it calls through to. The softokn
would just transparently add the appropriate module(s) to the list it
obtains from the DB.
In the short term, it would be quite nice to have a *plan* even if
it's going to take a while to come to fruition. In particular, it
would be nice to know what interim measures we can take — for example
can we add p11-kit-proxy.so to /etc/pki/nssdb/pkcs11.txt or would that
actually end up conflicting with whatever the real solution ends up
looking like? Or should we patch high-priority applications just to
load
p11-kit-proxy.so for themselves, and if so should it be made
conditional... and on what? On the presence of a new PK11_FindCertByURI
function or something like that,
perhaps?
--
dwmw2
¹ http://mxr.mozilla.org/nss/source/lib/pk11wrap/pk11load.c#379
smime.p7s
Description: S/MIME cryptographic signature
-- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
