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

[Vincent Le T. <vin...@my...>]

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 <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?"
>
> (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
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>
>


-- 
--
Vincent Le Toux

My Smart Logon
www.mysmartlogon.com