Re: [Opensc-devel] Adding libp11 (or its equivalent) to OpenSSL

[Andreas J. <an...@io...>]

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