Adding libp11 (or its equivalent) to OpenSSL
Locked
12
12
Adding libp11 (or its equivalent) to OpenSSL
 
|
It would be really useful if OpenSSL *included* support for PKCS#11 as
a first class citizen. This would mean that it could be natively incorporated into higher level APIs such as SSL_CTX_use_certificate() and friends. Basically any API that can take a filename to reference a certificate, should also be able take a RFC7512 PKCS#11 URI. This would also allow us to use a coherent trust database from PKCS#11, which solves the problem of which *purposes* we trust each CA for, unlike the existing flat-file solutions. And applications would no longer need to jump through additional hoops and have additional dependencies to get PKCS#11 support; we could make it largely Just Work™, like it does for example with GnuTLS. The code in libp11 is basically written to be OpenSSL code. If you dropped it into the crypto/pkcs11 directory of OpenSSL precisely as it stands, it wouldn't look out of place. I propose — as the starting point of a plan which will surely be modified by the time we conclude this thread — that we do so. The biggest barrier to this, of course, is the licence. For reasons which are lost in the mists of time, libp11 is licensed under the LGPLv2, and is not compatible with the OpenSSL licence. Therefore, I propose that we relicense the libp11 project under a standard 3-clause BSD licence. I did a bit of a sanity check offline, and I contacted Olaf Kirch as well as the top contributors responsible¹ for 8611 of the 8984 lines of .[ch] files in the repository. All of whom so far have agreed to allow their contributions to be re-used under a BSD licence. That gives me reasonable confidence that we can all agree, and that if there *are* some people we can't find, or who don't agree, we can reimplement the corresponding lines of code without too much of a problem. If you have ever contributed to libp11 (or the engine, although I wasn't going there yet), I would be very grateful for an explicit response to the question: "May I re-use your code under the 3-clause BSD licence as seen at https://opensource.org/licenses/BSD-3-Clause?" (There is a separate question, if we get that far, which is "shall we *change* the licence of the libp11 project to 3-clause BSD?". Personally I'd say yes to that too.) So next we come to the technical approach, and I'd really appreciate feedback here. Do we *want* to drop the libp11 API directly into OpenSSL? That might be ideal from the point of view of existing applications as they migrate from OpenSSL <=1.1 + libp11, to OpenSSL 1.2. Or perhaps we want to take this opportunity to change the API? Perhaps libp11 would continue to exist alongside OpenSSL 1.2 for compatibility with those existing apps? (That question is specifically aimed as the OpenSSL folks on Cc as well as the libp11 list.) For a start, I definitely think we should at least add functions for obtaining an EVP_PKEY or an X509 cert from a PKCS#11 URI alone — similar to the pkcs11_load_key() and pkcs11_load_cert() functions in the engine code. I'm also tempted to suggest that we should make it capable of using p11-kit for the basic module loading and initialisation. Since p11-kit is "sufficiently ubiquitous" on the platforms where this is relevant, my approach would probably be to *start* by depending on p11-kit, and if anyone objects they can do so in 'diff -up' form. Starting with a full implementation of RFC7512 URI parsing... Once we have a consensus on what the resulting API would look like, my idea would be to create a sequence of submissions to OpenSSL (not for 1.1 but to be merged to OpenSSL HEAD after that), which slowly add the required functionality step by step (probably leaving out the deprecated functions). Each commit would then be easily reviewable for merging into OpenSSL. And where it's lifted from existing libp11 code, I could properly check the provenance of each line of code as I go, to make sure I do have permission to relicense it. That's about as far as my plan goes, really. The point here is to solicit feedback and work out how best to proceed... Please note there are two members of the OpenSSL team in Cc. Please make sure you "reply to all" and don't drop them. -- dwmw2 ¹ According to 'git blame', which I appreciate is a blunt tool and doesn't even credit Olaf with any lines of code. But as a sanity check for "should I give up on this idea and just write something from scratch?" it's OK. Specifically: $ for a in `find . -name \*.[ch]` ; do git blame $a; done | sed 's/........ (\(.*\)[[:space:]]*20..-..-.. ..:..:.. .*/\1/' | sed s/[[:space:]]*$// | sort | uniq -c | sort -rn 4559 Michał Trojnara 2813 Andreas Jellinghaus 749 Doug Engert 454 Nikos Mavrogiannopoulos 163 Ludovic Rousseau 59 Mikhail Denisenko 45 Alon Bar-Lev 44 Stephane Adenot 39 Nils Larsch 32 Michal Trojnara 9 Martin Paljak 6 Anton Fedorov 4 David Woodhouse 3 Christian Heimes 2 Mike Gerow 2 Jean-Pierre Szikora 1 LE TOUX Vincent ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 _______________________________________________ Opensc-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/opensc-devel |
smime.p7s (7K)
Re: Adding libp11 (or its equivalent) to OpenSSL
|
|
Re: Adding libp11 (or its equivalent) to OpenSSL
|
|
Re: Adding libp11 (or its equivalent) to OpenSSL
|
|
In reply to this post by David Woodhouse
On Fri, 2016-02-26 at 16:30 +0000, Salz, Rich wrote:
> This sounds like a great project. But just to make it clear: it's > something for after 1.1. That is, if there's no time to do work > until May, that's okay :) Absolutely. Even if we had instant unanimous agreement on the licensing, and by some magic there was no extra work to be done there to make sure it's all good — and if we had instant unanimous agreement from both the OpenSSL and OpenSC side that dropping libp11 into crypto/pkcs11 *verbatim* was the right thing to do, I don't think I'd be suggesting that we try to get this into 1.1 in the ... 8? ... working days we have left before Beta1. I plan to spend that time chasing the fixes required for the UEFI build :) -- dwmw2 ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 _______________________________________________ Opensc-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/opensc-devel |
Re: Adding libp11 (or its equivalent) to OpenSSL
|
|
Re: Adding libp11 (or its equivalent) to OpenSSL
|
|
On Fri, 2016-02-26 at 19:12 +0200, Alon Bar-Lev wrote:
> > What you should ask first from openssl developers is to extend their > engine concept to support keystore concept. > Then, at least, integration with openssl will be easier. Actually, they *volunteered* precisely that suggestion. Apologies, I forgot to mention it. Thanks for the suggestion. But this is actually more relevant for the next stage; the fuller *integration* into OpenSSL. -- dwmw2 ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 _______________________________________________ Opensc-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/opensc-devel |
Re: Adding libp11 (or its equivalent) to OpenSSL
|
|
Re: Adding libp11 (or its equivalent) to OpenSSL
|
|
Re: Adding libp11 (or its equivalent) to OpenSSL
|
|
Re: Adding libp11 (or its equivalent) to OpenSSL
|
|
Re: Adding libp11 (or its equivalent) to OpenSSL
|
|
Re: Adding libp11 (or its equivalent) to OpenSSL
|
|
Re: Adding libp11 (or its equivalent) to OpenSSL
|
|
Re: Adding libp11 (or its equivalent) to OpenSSL
|
|
In reply to this post by Michael Jackson
On Fri, 2016-02-26 at 23:22 +0200, Michael Jackson wrote:
> You can see reports of it all over the googlespace: > > https://www.google.com/#q=openssl+engine+missing+libgost.so > > Engine will simply refuse to load any engine if libgost.so is not > present on the system. Remove your libgost.so and give it a try ;-) > Or, just spin up a RHEL 7 or variant VM and give it a try. Haven't > tried it with Fedora. The engine works fine in Fedora. In fact, Fedora packaging guidelines now say that packages which use OpenSSL SHOULD be transparently accepting PKCS#11 URIs wherever they can take filenames for certificates. Which means more things are using the engine than before. If it's actually broken in RHEL/CentOS, I'd expect to see a Red Hat bug filed for that. A reference in bugzilla.redhat.com is the only relevant one. But as Alon says, that's not strictly relevant to this discussion. -- dwmw2 ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 _______________________________________________ Opensc-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/opensc-devel |
Re: Adding libp11 (or its equivalent) to OpenSSL
|
|
In reply to this post by Michal Trojnara
On Fri, 2016-02-26 at 16:20 +0100, Michal Trojnara wrote:
> > I'm not sure what you mean by "depending on p11-kit". I agree p11-kit > simplifies configuration on some popular desktop platforms. My point > is OpenSSL is not exclusively used on desktop platforms. Shall we > really require p11-kit? Wouldn't it limit the portability of OpenSSL? > Shall we also merge p11-kit into OpenSSL? It would limit the portability of the platforms on which you can build OpenSSL with this hypothetical PKCS#11 support, sure. It would largely limit it to the set of platforms on which you'd really *want* to. :) With p11-kit we get proper integration into the system's configuration for which PKCS#11 modules should be loaded into which processes — again, a SHOULD in Fedora packaging guidelines, and a good idea elsewhere regardless. And we get also get proper support for accessing modules from multiple callers within the same process. But those *could* be solved just by using p11-kit-proxy.so as the default provider. That just leaves full PKCS#11 URI support, which I suppose we *could* reimplement... -- dwmw2 ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 _______________________________________________ Opensc-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/opensc-devel |
Re: Adding libp11 (or its equivalent) to OpenSSL
|
|
Re: Adding libp11 (or its equivalent) to OpenSSL
|
|
Re: Adding libp11 (or its equivalent) to OpenSSL
|
|
In reply to this post by Michael Jackson
On Fri, 2016-02-26 at 22:36 +0200, Michael Jackson wrote:
> Engine isn't even a first-class citizen in OpenSSL, doesn't get much > love anymore at all from the developers. Engine does not work on any > RHEL variants at the moment. Reason being is that Engine actually has > a downward dependency on one of it's plugins: Gost (Russian Federal > Crypto standard). If libgost.so is missing from a system, OpenSSL will > refuse to load Engine wholesale. And libgost.so is not included in the > RH builds of OpenSSL. I happened to be prodding at a RHEL7 box today, so I checked this. It looks like engine_pkcs11 isn't present in RHEL or even EPEL, so I built it myself. It seems to work fine... $ openssl req -engine pkcs11 -new -key "pkcs11:token=NSS%20Certificate%20DB;object=test-key;type=private" -keyform engine -text -x509 -subj "/CN=dwmw2" engine "pkcs11" set. Certificate: Data: Version: 3 (0x2) Serial Number: 13141336097864957623 (0xb65f678e23423eb7) Signature Algorithm: sha256WithRSAEncryption Issuer: CN=dwmw2 Validity Not Before: Feb 26 23:02:29 2016 GMT Not After : Mar 27 23:02:29 2016 GMT Subject: CN=dwmw2 -- David Woodhouse Open Source Technology Centre [hidden email] Intel Corporation ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 _______________________________________________ Opensc-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/opensc-devel |
Re: Adding libp11 (or its equivalent) to OpenSSL
|
|
Re: Adding libp11 (or its equivalent) to OpenSSL
|
|
| Free forum by Nabble | Edit this page |