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 |
Hi David, As the person listed at the last position "LE TOUX Vincent", you can do whatever you want with the code I wrote (sublicense, relicense, ...). Note: I think I wrote code only about integration in Appveyor, not c code. regards, Vincent 2016-02-26 15:19 GMT+01:00 David Woodhouse <[hidden email]>: It would be really useful if OpenSSL *included* support for PKCS#11 as -- ------------------------------------------------------------------------------ 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 |
In reply to this post by David Woodhouse
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256 On 26.02.2016 15:19, David Woodhouse wrote: > 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, you may. > (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.) Yes, we shall. > 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. Actually I recently merged the engine code into the libp11 repository. For OpenSSL it doesn't matter that the repository currently produces two separate libraries. > 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'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? Best regards, Mike -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJW0G1IAAoJEC78f/DUFuAUpysP/1CyYsM7sIaij1+40RQll4lw qiSbSWtPngXSxE8QJnIQdvBm3qByb+DLCShkm4arJC+DWauEdzA7uetrB9PNRzH3 +Mtd1+uOOgP4h8ERt7Kizci4Yns4MvwRPntTb/fC6vmL/wXx9Txznpw5YPHTuo/B rb862yTrk/Hf/kH7sFU4ynUSSs8JhwFPXWqQAsO0MiVv/INPM5APiV0RP7Nc6iuK NJWfb0QPmmezDPYy/4e22h+UPqUq371IWdswX32wlMx9k3aSUSe1JEZZkgpCXaYM IQNuGvf4LIRQy591ME+fDRJQFCt/X3N7b7lAeXKEl7SfZ5mXF/0CNirQDNNM1e7O 9XfHbwrqYFn8pC2XG+YONwMy/6L8X5y+EwkIXGXgE7DvxgDjfzrbpgI5VmcQnQVC qbF5Y2dvp/zBAAJnX/Nk3BnMZn/Hh2GoesY30QMgvINZrNJgLry5PYhnIo+DRmls 3UM1TPC1v+/6GziLkSD7LlaBSwUMdc2JBtv+y4Gnul5TvGFGqqY3crobrIgCneJy HYWJhgyv9hwz1Cieuo4gcqDCQ/jJy2bYrOYrljSWCqH16MnwRW78Vekm7PT7PFGu BVNmGO/nzMIYmU8evW8/XNnhFxMwexyiTWIhLrSbaxxamBO6i1QRj/yJ3fTaZYoe mR0YeeUxj80aojOpK+gq =oQh8 -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ 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 |
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 |
In reply to this post by David Woodhouse
On 26 February 2016 at 16:19, David Woodhouse <[hidden email]> wrote: It would be really useful if OpenSSL *included* support for PKCS#11 as 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. 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.Then, at least, integration with openssl will be easier. ------------------------------------------------------------------------------ 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 |
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 |
In reply to this post by David Woodhouse
2016-02-26 15:19 GMT+01:00 David Woodhouse <[hidden email]>: It would be really useful if OpenSSL *included* support for PKCS#11 as OK for me. I don't even remember what code I wrote for libp11 :-) Bye -- Dr. Ludovic Rousseau
------------------------------------------------------------------------------ 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 |
In reply to this post by Alon Bar-Lev
On February 26, 2016 6:12:35 PM GMT+01:00, Alon Bar-Lev <[hidden email]> 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. There is such a project that I have been tinkering with periodically, called STORE. It won't be part of 1.1, sadly, but I'm maintaining a branch with the aim to resurrect it in master once 1.1 is out. David showed an interest in this STORE recently. I'll make sure to make that branch available on github. Cheers Richard -- [hidden email] ------------------------------------------------------------------------------ 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 |
In reply to this post by Ludovic Rousseau
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. Additionally, Engine has been entirely ripped out from LibreSSL so that excludes at least OpenBSD as well, maybe also Free and NetBSD, too. Building a second OpenSSL on a system just so you can build libgost.so, and thus be able to use Engine and pkcs11_engine, is not a trivial task because OpenSSL contains hardcoded library paths. You need to actually patch their extremely long Configure script to make it build with rpath. After the heartbleed fiasco, RH has been switching as much as possible to use NSS and stopped linking against OpenSSL. NSS is probably far more portable than OpenSSL, and would probably be a better target for integration. On Fri, Feb 26, 2016 at 8:13 PM, Ludovic Rousseau <[hidden email]> wrote: > > > 2016-02-26 15:19 GMT+01:00 David Woodhouse <[hidden email]>: >> >> 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. > > > OK for me. > > I don't even remember what code I wrote for libp11 :-) > > Bye > > -- > Dr. Ludovic Rousseau > > ------------------------------------------------------------------------------ > 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 > ------------------------------------------------------------------------------ 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 |
In message <CANCEyfMLpU8or+_bm1L0VJ=[hidden email]> on Fri, 26 Feb 2016 22:36:36 +0200, Michael Jackson <[hidden email]> said:
mikedotjackson> Engine isn't even a first-class citizen in OpenSSL, doesn't get much mikedotjackson> love anymore at all from the developers. Engine does not work on any mikedotjackson> RHEL variants at the moment. Reason being is that Engine actually has mikedotjackson> a downward dependency on one of it's plugins: Gost (Russian Federal mikedotjackson> Crypto standard). If libgost.so is missing from a system, OpenSSL will mikedotjackson> refuse to load Engine wholesale. And libgost.so is not included in the mikedotjackson> RH builds of OpenSSL. Additionally, Engine has been entirely ripped mikedotjackson> out from LibreSSL so that excludes at least OpenBSD as well, maybe mikedotjackson> also Free and NetBSD, too. Uhmmm... color me surprised, 'cause what you tell me doesn't correspond to this developer's (hello, hi) experience. I'm not sure what would make the ENGINE framework refuse to work without GOST, and I'm also utterly surprised to have seen no reports at all about this. Cheers, Richard -- Richard Levitte [hidden email] OpenSSL Project http://www.openssl.org/~levitte/ ------------------------------------------------------------------------------ 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 |
In reply to this post by Alon Bar-Lev
[resend]
On February 26, 2016 6:12:35 PM GMT+01:00, Alon Bar-Lev <[hidden email]> 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. There is such a project that I have been tinkering with periodically, called STORE. It won't be part of 1.1, sadly, but I'm maintaining a branch with the aim to resurrect it in master once 1.1 is out. David showed an interest in this STORE recently. I'll make sure to make that branch available on github. Cheers Richard -- Richard Levitte [hidden email] OpenSSL Project http://www.openssl.org/~levitte/ ------------------------------------------------------------------------------ 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 |
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. On the other note, OpenSSL configure/build system also ignores LDFLAGS entirely which makes it very difficult to relocate entirely independent of the system OpenSSL. On Fri, Feb 26, 2016 at 10:52 PM, Richard Levitte <[hidden email]> wrote: > [resend] > > On February 26, 2016 6:12:35 PM GMT+01:00, Alon Bar-Lev <[hidden email]> 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. > > There is such a project that I have been tinkering with periodically, > called STORE. It won't be part of 1.1, sadly, but I'm maintaining a > branch with the aim to resurrect it in master once 1.1 is out. > > David showed an interest in this STORE recently. > > I'll make sure to make that branch available on github. > > Cheers > Richard > > -- > Richard Levitte [hidden email] > OpenSSL Project http://www.openssl.org/~levitte/ > > ------------------------------------------------------------------------------ > 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 ------------------------------------------------------------------------------ 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 |
On 26 February 2016 at 23:22, Michael Jackson <[hidden email]> 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. > > On the other note, OpenSSL configure/build system also ignores LDFLAGS > entirely which makes it very difficult to relocate entirely > independent of the system OpenSSL. I believe you are confusing between binary and source based distributions. Also, although openssl build system is completely proprietary one, you can customize it for your need, it just takes a lot of time to learn it. These two issues are irrelevant to this discussion. ------------------------------------------------------------------------------ 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 |
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 |
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 |
In reply to this post by Michael Jackson
> You can see reports of it all over the googlespace:
> > https://www.google.com/#q=openssl+engine+missing+libgost.so I took a look. Most seemed to be 2013 or earlier. ENGINE was a second-class citizen within OpenSSL. Heck, most of the source base was a second-class citizen for a very long time. Things Are Different now. Honest. For example, GOST is now completely implemented as an engine, and not distributed with OpenSSL. Give it another chance :) You'll probably like what you see, or at least dislike it less. -- Senior Architect, Akamai Technologies IM: [hidden email] Twitter: RichSalz ------------------------------------------------------------------------------ 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 |
In reply to this post by David Woodhouse
On 26 February 2016 at 22:42, David Woodhouse <[hidden email]> wrote:
That just leaves full PKCS#11 URI support, which I suppose we I should be able to contribute full PKCS#11 URI parser code from our private engine implementation. Just let me know if you are interested. Regards, Jaroslav ------------------------------------------------------------------------------ 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 |
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 |
In message <[hidden email]> on Fri, 26 Feb 2016 23:12:56 +0000, David Woodhouse <[hidden email]> said:
dwmw2> On Fri, 2016-02-26 at 22:36 +0200, Michael Jackson wrote: dwmw2> > Engine isn't even a first-class citizen in OpenSSL, doesn't get much dwmw2> > love anymore at all from the developers. Engine does not work on any dwmw2> > RHEL variants at the moment. Reason being is that Engine actually has dwmw2> > a downward dependency on one of it's plugins: Gost (Russian Federal dwmw2> > Crypto standard). If libgost.so is missing from a system, OpenSSL will dwmw2> > refuse to load Engine wholesale. And libgost.so is not included in the dwmw2> > RH builds of OpenSSL. dwmw2> dwmw2> I happened to be prodding at a RHEL7 box today, so I checked this. It dwmw2> looks like engine_pkcs11 isn't present in RHEL or even EPEL, so I built dwmw2> it myself. It seems to work fine... dwmw2> dwmw2> $ openssl req -engine pkcs11 -new -key "pkcs11:token=NSS%20Certificate%20DB;object=test-key;type=private" -keyform engine -text -x509 -subj "/CN=dwmw2" dwmw2> engine "pkcs11" set. dwmw2> Certificate: dwmw2> Data: dwmw2> Version: 3 (0x2) dwmw2> Serial Number: 13141336097864957623 (0xb65f678e23423eb7) dwmw2> Signature Algorithm: sha256WithRSAEncryption dwmw2> Issuer: CN=dwmw2 dwmw2> Validity dwmw2> Not Before: Feb 26 23:02:29 2016 GMT dwmw2> Not After : Mar 27 23:02:29 2016 GMT dwmw2> Subject: CN=dwmw2 I checked one of those claims that I found on Google, where the command 'host' would fail if libgost.so wasn't present (I could reproduce that on my laptop). It turns out that libgost.so is normally required when building Bind... I had a look at the source, and, well, lib/dns/opensslgost_link.c is telling the tale, and is built if libgost.so is available at the time of building Bind. So, I know OpenSSL is a popular scapegoat 'n all, especially since Heartblead, but frankly, we can't be blamed for what others decide to do with our toolkit. Now, I hope this question can be laid to rest and that we can return to the matter at hand. Cheers, Richard -- Richard Levitte [hidden email] OpenSSL Project http://www.openssl.org/~levitte/ ------------------------------------------------------------------------------ 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 |
In reply to this post by Michael Jackson
On Fri, 2016-02-26 at 22:36 +0200, Michael Jackson wrote:
> [...] > After the heartbleed fiasco, RH has been switching as much as > possible to use NSS and stopped linking against OpenSSL. NSS is > probably far more portable than OpenSSL, and would probably be a > better target for integration. I do not believe you are a Red Hat spokesperson, and as far as I know none of these are true. regards, Nikos ------------------------------------------------------------------------------ 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 |
Free forum by Nabble | Edit this page |