RFC7512 PKCS#11 URI support

As Varun ramps up for the potential GSoC project on implementing URI
support, I'd really like to get some consensus on the implementation
details — there is at least one choice which needs to be made, which
will affect his development from day one.

As discussed in https://bugzilla.mozilla.org/1162897 that is the
question of whether to use an external library (libp11-kit) for parsing
and handling the URIs, or whether to reinvent the wheel.

I think we should use libp11-kit. Both for the reasons that Ryan
mentions in Comment #1 of the above bug, and also because p11-kit gives
us other things that we'll need in future as we improve system
integration (specifically, co-ordinating the use of the same PKCS#11
provider modules from multiple places within the same process).

But for now, all we need is the URI parsing.

P11-kit is a BSD-licensed project, which builds on OSX and Windows:
https://p11-glue.freedesktop.org/

It is a fundamental part of all the major Linux desktop distributions,
and thus fairly much ubiquitous there. For fun I tried removing it
recently on OpenSuSE, Fedora and Ubuntu — in all cases it basically
wanted to remove most of the distro. Running 'dnf remove p11-kit' won't
even play any more on Fedora. It just tells me that would require
removing systemd and dnf itself, and tells me 'no'.

So my proposal that on platforms where p11-kit exists, NSS should just
link to it. But also, to avoid having to build and ship a separate
library on platforms which didn't already have it, I think we should
*import* the URI handling code from libp11-kit. That is mostly isolated
to one file, of 1305 lines which compiles to roughly 10KiB of code
under Linux/x86_64.

Does that seem like the correct approach?


The other open question, although it doesn't block the work at the
start of the project, is whether we should be extending
PK11_FindCertFromNickname() to accept RFC7512 URIs or whether we should
*only* accept URIs in a new function.

I understand Ryan's reticence (again, in comment #1) about
retroactively starting to accept URIs. But as noted in my response
there, I'm not sure it's really that dangerous — I can't see a
situation in which a valid PKCS#11 URI is passed into that function and
getting the corresponding object (instead of a failure) is a *bad*
thing.

On the contrary, it's a *good* thing in most cases. Because it means
that NSS-using applications which take a certificate identity on the
command line or in a config file, suddenly Just Work when they're
provided with a PKCS#11 URI instead. And if we force them to update to
a new API to do that, we get to do a bombing run on all those
applications to change them.

-- 
dwmw2

-- 
dev-tech-crypto mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-crypto