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