On Mon, 2016-08-29 at 21:55 +0200, David Sommerseth wrote: > There have been some proposals to ditch pkcs11-helper and rather use a > newer and more compliant library instead (p11-kit). I think this > makes more sense, to be honest. There are more issues with > pkcs11-helper which upstream seems less interested in resolving, among > others challenges with systemd and the PIN code [1]. So as things > start to pile up, I think it's better to move on to something else.
You fixed up the missing [1] link, but this one covers the underlying cause of the same issue, and highlights a little bit more why I *really* think we want to ditch pkcs11-helper as soon as possible: https://github.com/OpenSC/pkcs11-helper/issues/5 > Of course, someone needs to do this job. JJK sponsored me with a > PKCS#11 token at last hackathon + since that time I've gotten myself > both a Yubikey Neo and a NitroKey so I believe I have what's needed to > begin to dive into this rabbit hole ... I just need to get this > prioritized on my TODO list. Unless someone else wants to give it a > try, if so let me know and we'll see if I can help out somehow. Note that you don't need hardware. If you use Firefox or Chrome web browsers, you have a software PKCS#11 token. If you use the GNOME desktop, you have another one. Then there's SoftHSM and plenty of others. Anyone can test this stuff, fairly easily. > With that in mind, if shipping a patched pkcs11-helper in Windows > makes your life easier I'd consider doing this. But step carefully, > avoid getting in a situation where you suddenly have to maintain these > patches yourself. Rather try to see what Fedora does and see if that > can be re-used as much as possible. The Fedora patch for adding RFC7512 support is precisely the same as in the open pull request at https://github.com/OpenSC/pkcs11-helper/pull/4 It shouldn't need much ongoing maintenance. But I do definitely think it would be good to move away from pkcs11-helper completely. I'd actually like to remove it from Fedora entirely. There are only a small handful of projects which use it, and they can all be fixed. That said, ditching it completely and moving to something based on p11-kit and/or libp11 would make a lot of sense. I'm just not *100%* sure what that solution looks like. I know *most* of it but just not the final details. To clarify the difference between those two a little... p11-kit gives a system-wide configuration for which PKCS#11 provider modules should be available — distribution packages of stuff like SoftHSM, OpenSC, etc. should all provide p11-kit 'module' files so I can plug in my Yubikey and this Just Works™: dnf install opensc; openconnect -c 'pkcs11:manufacturer=piv_II;id=%01'… The p11-kit library also offers RFC7512 URI parsing, and enumeration of the various available PKCS#11 tokens and the objects there in. Its API is at https://p11-glue.freedesktop.org/doc/p11-kit/reference.html What p11-kit does *not* do is the actual crypto. It's completely crypto-library-agnostic. It'll give you the CK_OBJECT_HANDLE of the key in the token, but won't *use* it for you. You need a wrapper to actually make that available as an OpenSSL EVP_PKEY, or whatever the equivalent abstract key type is in mbedTLS. Those crypto operations *are* provided for OpenSSL by libp11, and for both OpenSSL and mbedTLS by pkcs11-helper. Along with a subset of the other functionality which we don't actually *need* because p11-kit provides it these days. But libp11 and pkcs11-helper predate, and don't use, p11-kit. So if we want to use p11-kit, we need to fill in the missing parts that actually let us *do* the crypto. Which isn't stunningly hard; we can lift those parts from pkcs11-helper for the most part. And all the token/object enumeration parts can be generic. Also, in the long term I actually want to merge native PKCS#11 support (probably using p11-kit) into OpenSSL itself as a first-class citizen. This plan has at least been approved in principle by the OpenSSL team as a "post 1.1" goal. The basic concept was to merge something like the libp11 API, but obviously it'll be subject to review as it goes in. And it *would* make sense to base it on p11-kit as much as possible. -- dwmw2
smime.p7s
Description: S/MIME cryptographic signature
------------------------------------------------------------------------------
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
