From: Alon Bar-L. <alo...@gm...> - 2016-02-29 21:05:48
|
On 29 February 2016 at 10:25, David Woodhouse <dw...@in...> wrote: > > On Fri, 2016-02-26 at 19:12 +0200, Alon Bar-Lev wrote: > > > > What you seek is actually NSS. > > This won't happen, ever. > > Even if it will happen, libp11 is not the right implementation of > > doing that. > > Yeah, we don't want NSS. NSS has its own problems :) > > When I say we want to make PKCS#11 a first-class citizen in OpenSSL, I > don't mean we want to rearchitect OpenSSL to be completely based around > PKCS#11, as NSS is. I only mean that we want the PKCS#11 functionality > (like that of libp11 or indeed pkcs11-helper) to be a *part* of > OpenSSL's APIs. So that anyone using OpenSSL could reasonably be > *expected* to support certificates/keys from PKCS#11 whenever they > support using them from a file. I believe it will be a mistake to introduce PKCS#11 into OpenSSL. The engine should be extended up to a point in which someone can implement and engine that can leverage any crypto interface, CryptoAPI, PKCS#11 or whatever. There is much work to be done at OpenSSL level, for example a certificate/key/crl store, hierarchy awareness (a set of keys are stored on a device, a set of devices can be accessed via same engine instance), dynamic content to enable removal and re-introduce keyset without destroying context, events for key/device availability/removal. One of the major challenges is to delegate CPU time to the engine for house keeping and idle tasks. Another challenge is to resolve threading issues. An asynchronous engine interface will resolve most of the issues. > > I have experience in working with openssl codebase and it won't be > > extended to support such specific implementation. > > There was the opencryptoki project, that was the closest one of doing > > that without adding any code to openssl. > > The point here *is* to add code to OpenSSL. That's why we have OpenSSL > developers on Cc, who are interested in making this happen. > > Your ideas on what the OpenSSL API should look like would be very much > welcomed. You're absolutely right that it shouldn't turn into NSS, and > I have already been talking to Rich about the keystore. Any more > insight, either in advance or as I proceed with trying to put something > together, would be very much appreciated; thanks! > > Just as importantly, please could you agree to the use of your code in > libp11 under a 3-clause BSD licence? Whether or not the final OpenSSL > 1.2 API actually looks like libp11 or not, I'm fairly sure there *will* > be a lot of opportunity for code re-use, and the permission to > relicense it would be very much appreciated. Fine by me, but again, libp11 is not the quality nor mindset of what OpenSSL should merge. Regards, Alon |
From: David W. <dw...@in...> - 2016-02-29 21:34:07
Attachments:
smime.p7s
|
On Mon, 2016-02-29 at 23:05 +0200, Alon Bar-Lev wrote: > I believe it will be a mistake to introduce PKCS#11 into OpenSSL. > The engine should be extended up to a point in which someone can > implement and engine that can leverage any crypto interface, > CryptoAPI, PKCS#11 or whatever. You mean the engine API, rather than specifically engine_pkcs11, yes? That does seem like a reasonable approach. The STORE that Rich has been working on does sound like it would facilitate this. The thing is, I absolutely DO NOT CARE how we do it. I'm more than happy to listen to your thoughts on how it should be done. My primary aim is just when applications use OpenSSL, it shall be expected that *wherever* they could use a filename to specify a certificate or key, it should Just Work™ if the user provides a PKCS#11 URI instead (in the config file, on the command line, or wherever). Further than that, I really don't care about much at all :) > There is much work to be done at OpenSSL level, for example a > certificate/key/crl store, hierarchy awareness (a set of keys are > stored on a device, a set of devices can be accessed via same engine > instance), dynamic content to enable removal and re-introduce keyset > without destroying context, events for key/device > availability/removal. Those sound useful, although I wouldn't class all of them as imperative for my own purposes. I'd certainly want to ensure that whatever design we end up with *can* support those. Even if some of them are left as an exercise for later implementation. > > Just as importantly, please could you agree to the use of your code > > in libp11 under a 3-clause BSD licence? > Fine by me, Thank you. > but again, libp11 is not the quality nor mindset of what > OpenSSL should merge. It provides a lot of the basic PKCS#11 functionality for loading modules and invoking them. I suspect we can use a lot of it even if we *then* stop and take a closer look at how it should be seamlessly *integrated* into the OpenSSL API set. I see it as a two-phase project in that sense. And I get the impression most of your commentary is about the second phase. -- dwmw2 |
From: Andreas J. <an...@io...> - 2016-03-01 15:34:43
|
Sorry for the late response. Responding once more to give a public statement. Comments inline below, I suppose your email reader can trim the quoted section, thus not spending time on that myself. 2016-02-26 15:19 GMT+01:00 David Woodhouse <dw...@in...>: > 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?" > Yes, all code from me for libp11 may be re-used under the BSD-3 clause. Same applies to engine_pkcs11 or pam_p11 (the two users of libp11 that I'm aware off), in case that is helpful. Please note that I created libp11 mostly by splitting engine_pkcs11/opensc code into a new project, so that I can use it for a pam module I was adding. At least that is how I remember it. Thus most code under my name might come from Olaf Kirch instead, but he has given the same approval already for all I know. (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.) > If anyone wants to maintain libp11 and wants to change the license: all ok from my side. > 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.) > I don't know current users or use cases who/how libp11 is being used. For me it is important there is a nice story at the end: this is how you can use smart cards. The work I did a few years ago included opensc, openct, pam_p11, engine_pkcs11, libp11 and openssl. If there is an updated story with other components, fine with me as well. The result counts for me, the details on how to get there: not that much. In theory it would be fine if people still could use a smart card or usb crypto token for both SSL connections, ssh connections and console login. In practice maybe noone is interested in maintaining that, and then it is ok if some progress on one side kills unmaintained code elsewhere. If there is sufficient interest, the code is easy enough to understand and adapt I think. 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... > I haven't kept up with that RFC or p11-kit, thus can't comment on what is the best way here. As this is open source: do what you think is right :) Thanks for taking on this project! I'm glad to see someone improves the support for smart card / hardware based authentication into our daily live. Andreas 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 > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensc-devel > > |
From: David W. <dw...@in...> - 2016-03-01 16:43:16
Attachments:
smime.p7s
|
On Tue, 2016-03-01 at 16:12 +0100, Andreas Jellinghaus wrote: > Yes, all code from me for libp11 may be re-used under the BSD-3 clause. > Same applies to engine_pkcs11 or pam_p11 (the two users of libp11 > that I'm aware off), in case that is helpful. Thank you. > Please note that I created libp11 mostly by splitting > engine_pkcs11/opensc code into a new project, so that I can use it > for a pam module I was adding. At least that is how I remember it. > Thus most code under my name might come from Olaf Kirch instead, but > he has given the same approval already for all I know. Actually, the interesting part starts before that. You moved the code out from OpenSC to separate engine_pkcs11 and libp11 repositories in August/September 2005. But they all appeared, in a big lump, in OpenSC in May 2003: https://github.com/OpenSC/OpenSC/commit/496232d9b Where did they come from before that? There are commits earlier in the OpenSC history which strongly imply that the engine code was already there — Olaf's commit f169b5c891 tweaks some autoconf code and is titled "only build sslengine if OpenSSL supports it". But according to the git history there *is* no code at that point; only the autoconf test... -- dwmw2 |
From: Andreas J. <an...@io...> - 2016-03-01 20:25:24
|
2016-03-01 17:43 GMT+01:00 David Woodhouse <dw...@in...> > > Actually, the interesting part starts before that. You moved the code > out from OpenSC to separate engine_pkcs11 and libp11 repositories in > August/September 2005. > > But they all appeared, in a big lump, in OpenSC in May 2003: > https://github.com/OpenSC/OpenSC/commit/496232d9b > > Where did they come from before that? > http://archive.debian.org/debian/pool/main/o/opensc/opensc_0.9.6.orig.tar.gz src/sslengines has the source code from Olaf and Kevin Stefanik. Many files are already using the BSD-2 or OpenSSL license. Also maybe someone has a backup of the old SVN server? my backup disk died some year ago, after the project was moved already to github and the server was retired :( Regards, Andreas There are commits earlier in the OpenSC history which strongly imply > that the engine code was already there — Olaf's commit f169b5c891 > tweaks some autoconf code and is titled "only build sslengine if > OpenSSL supports it". But according to the git history there *is* no > code at that point; only the autoconf test... > > -- > dwmw2 > > |
From: Andreas J. <an...@io...> - 2016-03-01 20:40:06
|
found it, commit b2455b097f8bd9b0a075df3820ce21c6bf33357a in engine_pkcs11 has the same content as opensc in commit bae2b51e01e16c126613289dd68e75545d3dd333 at least for these files: aj@seiryu:~/opensc-git/src/sslengines$ md5sum ~/xx/xx/engine_pkcs11/src/* f16abeabca8f30197b94f5cbbed56132 /home/aj/xx/xx/engine_pkcs11/src/engine_pkcs11.c e693a2a09ee07964722d71f1afbf1882 /home/aj/xx/xx/engine_pkcs11/src/engine_pkcs11.def 9936c4fc0357e7c24ddc12abe66fcd06 /home/aj/xx/xx/engine_pkcs11/src/engine_pkcs11.h e4d4f039411f964636b11973d5617ffc /home/aj/xx/xx/engine_pkcs11/src/hw_opensc.c 8f7565d60db0ad6246c50b3282676bbf /home/aj/xx/xx/engine_pkcs11/src/hw_pkcs11.c f4911e7a7cd3b44a4251ca8529f685bc /home/aj/xx/xx/engine_pkcs11/src/Makefile.am 003221d31d444bb8cd3ca09b7a305158 /home/aj/xx/xx/engine_pkcs11/src/Makefile.mak aj@seiryu:~/opensc-git/src/sslengines$ md5sum * 1a29991197312afe0b8d055e5912ce2f engine_opensc.c e4219829d19f13cc6c59f7a49d1d830c engine_opensc.h f16abeabca8f30197b94f5cbbed56132 engine_pkcs11.c e693a2a09ee07964722d71f1afbf1882 engine_pkcs11.def 9936c4fc0357e7c24ddc12abe66fcd06 engine_pkcs11.h e4d4f039411f964636b11973d5617ffc hw_opensc.c 8f7565d60db0ad6246c50b3282676bbf hw_pkcs11.c cae21328df67ce552a790779bf3e4015 Makefile.am 003221d31d444bb8cd3ca09b7a305158 Makefile.mak 0afa2a574a5f83c7fa52cfe35fbd9098 test_engine.sh thus the code can be tracked back to opensc that way. Also the code at that age is already BSD-2 or OpenSSL licensed. engine_pkcs11.def is trivial and I guess you have no need to reuse old Makefiles. Thus you should be all good? Regards, Andreas 2016-03-01 17:43 GMT+01:00 David Woodhouse <dw...@in...>: > On Tue, 2016-03-01 at 16:12 +0100, Andreas Jellinghaus wrote: > > > Yes, all code from me for libp11 may be re-used under the BSD-3 clause. > > Same applies to engine_pkcs11 or pam_p11 (the two users of libp11 > > that I'm aware off), in case that is helpful. > > Thank you. > > > Please note that I created libp11 mostly by splitting > > engine_pkcs11/opensc code into a new project, so that I can use it > > for a pam module I was adding. At least that is how I remember it. > > Thus most code under my name might come from Olaf Kirch instead, but > > he has given the same approval already for all I know. > > Actually, the interesting part starts before that. You moved the code > out from OpenSC to separate engine_pkcs11 and libp11 repositories in > August/September 2005. > > But they all appeared, in a big lump, in OpenSC in May 2003: > https://github.com/OpenSC/OpenSC/commit/496232d9b > > Where did they come from before that? > > There are commits earlier in the OpenSC history which strongly imply > that the engine code was already there — Olaf's commit f169b5c891 > tweaks some autoconf code and is titled "only build sslengine if > OpenSSL supports it". But according to the git history there *is* no > code at that point; only the autoconf test... > > -- > dwmw2 > > |
From: David W. <dw...@in...> - 2016-03-01 23:40:04
Attachments:
smime.p7s
|
On Tue, 2016-03-01 at 21:39 +0100, Andreas Jellinghaus wrote: > > thus the code can be tracked back to opensc that way. Also the code > at that age is already BSD-2 or OpenSSL licensed. The latter is the point I'd missed; thanks. I was worried about the provenance of the code when it *arrived* in OpenSC. But if it was already suitably licensed at that point, we don't need to care. The same appears to be true for the libp11 repository — you changed the licence when you moved the files to the new repository, so all we need to track is changes which were contributed *since* then, which is great. Thanks again. -- dwmw2 |