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

[David W. <dw...@in...>]

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