Ubsec and Chil engines

classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Ubsec and Chil engines

Richard Levitte - VMS Whacker-2
In message <[hidden email]> on Mon, 22 Feb 2016 14:46:28 +0000, "Salz, Rich" <[hidden email]> said:

rsalz> > If we integrate the support natively into OpenSSL, then PKCS#11 URIs (see
rsalz> > RFC7512) can be first-class citizens throughout the crypto and SSL APIs. Any
rsalz> > function which takes a filename for a cert or key should also accept¹ a
rsalz> > PKCS#11 URI.
rsalz>
rsalz> It'd be great to see a crypto/pkcs11 directory with full native support (as much as possible).
rsalz>
rsalz> But really doubtful to happen in 1.1 as the API freeze is in a month.

Yeah, 1.1 is unrealistic, I'm sorry to say.

--
Richard Levitte         [hidden email]
OpenSSL Project         http://www.openssl.org/~levitte/
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Ubsec and Chil engines

Blumenthal, Uri - 0553 - MITLL
In reply to this post by David Woodhouse-7
On 2/22/16, 6:12 , "openssl-dev on behalf of David Woodhouse"
<[hidden email] on behalf of [hidden email]> wrote:

>>It may even be better, instead of pushing for different engines for
>> different hardware, to make PKCS#11 the only API used to talk to
>> hardware. There is a quite functional (and active as project) pkcs11
>> engine for openssl [0].
>
>Agreed. With the caveat that I *really* want libp11 and engine_pkcs11
>to die, and be replaced by native code in openssl/crypto/pkcs11/

Would you mind explaining what you mean by “native code” that presumably
could replace the current libp11, and who in your opinion would support it?

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Ubsec and Chil engines

Nikos Mavrogiannopoulos-2
In reply to this post by Jaroslav Imrich
On Mon, 2016-02-22 at 15:08 +0100, Jaroslav Imrich wrote:

> On 22 February 2016 at 11:16, Nikos Mavrogiannopoulos <[hidden email]
> m> wrote:
> >  That's an implementation detail. As far as I know engine_pkcs11
> > does not require re-authentication after fork. It handles the
> > pkcs11 peculiarities internally.
> AFAIK this works by caching the PIN in engine_pkcs11 internally and
> is OK for most of the use cases with smartcards. However HSMs usually
> use more complex authentication schemes where this approach does not
> work i.e. in order to login there must be N of M physical
> tokens/cards with passwords presented in a sequence (requires vendor
> specific extensions when used via PKCS#11). CHIL engine already
> handles such schemes very well and does not need to reauthenticate
> after fork.

I find that discussion more suitable to the PKCS #11 working group than
here. It cannot be solved by openssl devevlopers. In any case, I don't
find the solution to any problem in a standardized API is "let's make
our own better API". Why not work towards fixing the PKCS #11 spec?

In any case, there _are_ PKCS #11 modules which continue working after
fork (opendnssec's softhsm for example). So the issue is not something
that cannot be addressed within PKCS #11.

regards,
Nikos

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Ubsec and Chil engines

David Woodhouse-7
In reply to this post by Salz, Rich
On Mon, 2016-02-22 at 14:46 +0000, Salz, Rich wrote:
> > If we integrate the support natively into OpenSSL, then PKCS#11 URIs (see
> > RFC7512) can be first-class citizens throughout the crypto and SSL APIs. Any
> > function which takes a filename for a cert or key should also accept¹ a
> > PKCS#11 URI.
>
> It'd be great to see a crypto/pkcs11 directory with full native support (as much as possible).
>
> But really doubtful to happen in 1.1 as the API freeze is in a month.

Sure, it'd be insane to target 1.1.... well, except that libp11 is
basically *designed* to be dropped into crypto/pkcs11 except for being
under the LGPL. And its original author has already agreed to relicense
it more sensibly.

But yeah — realistically speaking, we are talking about 1.2 (or
whatever comes next). We have libp11+engine_pkcs11 for now.

I absolutely don't want to waste the effort though, so seeing you say
things like "it'd be great to have" is actually really useful.

So let me outline the plan a little bit and see if you still think it's
a good idea...

I was intending to use libp11-kit for the basic PKCS#11 module
enumeration and handling. On the *nix platforms where PKCS#11 is most
important, p11-kit is fairly much ubiquitous. Obviously the code would
be designed such that if someone really wants to eliminate that
requirement, they could reimplement all the things that libp11-kit
gives us and make it a build-time option. But seriously, why would you?

I'd start by throwing together the code to implement the various
EVP_PKEY types work based on PKCS#11 calls, and then look at Richard's
STORE code and how we'd want to tie that in with the use of PKCS#11
URIs to identify objects.

If other libp11 contributors are happy to relicense, that means I can
lift big chunks of code from there. Otherwise I get to reinvent the
wheel.

--
David Woodhouse                            Open Source Technology Centre
[hidden email]                              Intel Corporation


--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Ubsec and Chil engines

David Woodhouse-7
In reply to this post by Blumenthal, Uri - 0553 - MITLL
On Mon, 2016-02-22 at 15:59 +0000, Blumenthal, Uri - 0553 - MITLL wrote:

> On 2/22/16, 6:12 , "openssl-dev on behalf of David Woodhouse"
> <[hidden email] on behalf of [hidden email]> wrote:
>
> > > It may even be better, instead of pushing for different engines for
> > > different hardware, to make PKCS#11 the only API used to talk to
> > > hardware. There is a quite functional (and active as project) pkcs11
> > > engine for openssl [0].
> >
> > Agreed. With the caveat that I *really* want libp11 and engine_pkcs11
> > to die, and be replaced by native code in openssl/crypto/pkcs11/
>
> Would you mind explaining what you mean by “native code” that presumably
> could replace the current libp11, and who in your opinion would support it?
Really, I mean "code within OpenSSL itself". In an ideal world, that
might actually *be* libp11, which is basically written as if it resides
in openssl/crypto/pkcs11/ already — except for its licence (qv).

So "die and be replaced by" would be the wrong wording for me to have
used. I want libp11 to stop being a *separate* project.

In particular — if I pick some random OpenSSL-using application, like
wpa_supplicant, and pass it a PKCs#11 URI instead of a filename as the
certificate/key, then I want it to Just Work™ through the normal
OpenSSL APIs, without the application author having to jump through
additional hoops to *make* it work.

(Note: the first part of that, "shall accept PKCS#11 URI in place of
filename" is part of the Fedora packaging guidelines these days. It is
expected that software packaged for Fedora SHOULD work that way. The
second part, with normal OpenSSL APIs actually facilitating that
improvement, is what we're talking about here.)

As for who would work work on it... well, it would be part of an
OpenSSL (1.2?) release, so the OpenSSL team would have a certain amount
of responsibility for it. But I expect that anyone who has had an
interest in libp11 in the days *before* OpenSSL 1.2 would continue to
have contributions for crypto/pkcs11/ in OpenSSL 1.2 onwards. As well
as *more* interest especially from the Linux distribution side, once we
make it possible to have coherent CA trust settings across the
distribution by having the trust database in PKCS#11, etc.

In fact, libp11 wasn't seeing a huge amount of development work before
people started adding EC support to it, was it? Other than keeping it
up to date with OpenSSL releases, of course...

I don't anticipate that it would be a large maintenance burden.

--
David Woodhouse                            Open Source Technology Centre
[hidden email]                              Intel Corporation


--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Ubsec and Chil engines

Sander Temme
In reply to this post by Richard Levitte - VMS Whacker-2
All,

I toyed over the weekend with resurrecting CHIL: intermediate result here https://github.com/sctemme/openssl/tree/rescue-chil and I AM NOT PROUD OF THIS but have no cycles to clean it up for at least a couple of days to come. It builds now but doesn't work: my privkey loading routine doesn't get called and that may be an API change I missed.

Can we resurrect CHIL for 1.1 along these lines? Then I'd be delighted to join the discussion about p11 for down the road.

S.

Sent from my iPhone

> On Feb 22, 2016, at 10:00 AM, Richard Levitte <[hidden email]> wrote:
>
> In message <[hidden email]> on Mon, 22 Feb 2016 14:46:28 +0000, "Salz, Rich" <[hidden email]> said:
>
> rsalz> > If we integrate the support natively into OpenSSL, then PKCS#11 URIs (see
> rsalz> > RFC7512) can be first-class citizens throughout the crypto and SSL APIs. Any
> rsalz> > function which takes a filename for a cert or key should also accept¹ a
> rsalz> > PKCS#11 URI.
> rsalz>
> rsalz> It'd be great to see a crypto/pkcs11 directory with full native support (as much as possible).
> rsalz>
> rsalz> But really doubtful to happen in 1.1 as the API freeze is in a month.
>
> Yeah, 1.1 is unrealistic, I'm sorry to say.
>
> --
> Richard Levitte         [hidden email]
> OpenSSL Project         http://www.openssl.org/~levitte/
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Ubsec and Chil engines

Nikos Mavrogiannopoulos-2
In reply to this post by Nikos Mavrogiannopoulos-2
-------- Forwarded Message --------
From: Robert Relyea <rrelyea@redhat.
com>
To: Nikos Mavrogiannopoulos <[hidden email]>
Cc: openssl-dev@openss
l.org
Subject: Re: [openssl-dev] Ubsec and Chil engines
Date: Tue, 23 Feb
2016 12:28:25 -0500 (EST)

----- Nikos Mavrogiannopoulos <[hidden email]> wrote:

> On Mon, 2016-02-22 at 15:08 +0100, Jaroslav Imrich wrote:
> > On 22 February 2016 at 11:16, Nikos Mavrogiannopoulos <nmav@redhat.
> > co
> > m> wrote:
> > >  That's an implementation detail. As far as I know engine_pkcs11
> > > does not require re-authentication after fork. It handles the
> > > pkcs11 peculiarities internally.
> > AFAIK this works by caching the PIN in engine_pkcs11 internally and
> > is OK for most of the use cases with smartcards. However HSMs
> > usually
> > use more complex authentication schemes where this approach does
> > not
> > work i.e. in order to login there must be N of M physical
> > tokens/cards with passwords presented in a sequence (requires
> > vendor
> > specific extensions when used via PKCS#11). CHIL engine already
> > handles such schemes very well and does not need to reauthenticate
> > after fork.

> I find that discussion more suitable to the PKCS #11 working group
> than
> here. It cannot be solved by openssl devevlopers. In any case, I
> don't
> find the solution to any problem in a standardized API is "let's make
> our own better API". Why not work towards fixing the PKCS #11 spec?

> In any case, there _are_ PKCS #11 modules which continue working
> after fork (opendnssec's softhsm for example). So the issue is not
> something that cannot be addressed within PKCS #11.

The osasis pkcs 11 group is already planning on updating the semantic in a future pkcs 11 release. You can track the technicial committee work here https://www.oasis-open.org/apps/org/workgroup/pkcs11 

If you have fully formed proposals for PKCS 11 let me know and we can look at adding it to the spec. 

Bob




--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Ubsec and Chil engines

Matt Caswell-2
In reply to this post by Sander Temme


On 23/02/16 16:38, Sander Temme wrote:

> All,
>
> I toyed over the weekend with resurrecting CHIL: intermediate result
> here https://github.com/sctemme/openssl/tree/rescue-chil and I AM NOT
> PROUD OF THIS but have no cycles to clean it up for at least a couple
> of days to come. It builds now but doesn't work: my privkey loading
> routine doesn't get called and that may be an API change I missed.
>
> Can we resurrect CHIL for 1.1 along these lines? Then I'd be
> delighted to join the discussion about p11 for down the road.

I would prefer to move CHIL to an external repo (e.g. maybe Richard's
engine corner??). As Richard said in another post, this code is
unmaintainable by us because no-one on the team has access to the
relevant hardware.

BTW, no one has spoken up for Ubsec, which was the other engine
mentioned in the original post, so I will be removing that one imminently.

Matt

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Ubsec and Chil engines

Blumenthal, Uri - 0553 - MITLL
In reply to this post by David Woodhouse-7
>>> Agreed. With the caveat that I *really* want libp11 and engine_pkcs11
>> > to die, and be replaced by native code in openssl/crypto/pkcs11/
>>
>> Would you mind explaining what you mean by “native code” that presumably
>> could replace the current libp11, and who in your opinion would support
>>it?
>
>Really, I mean "code within OpenSSL itself". In an ideal world, that
>might actually *be* libp11, which is basically written as if it resides
>in openssl/crypto/pkcs11/ already — except for its licence (qv).

Ah, I understand. Yes, we’re in complete agreement here.

>So "die and be replaced by" would be the wrong wording for me to have
>used. I want libp11 to stop being a *separate* project.

:-)

>In fact, libp11 wasn't seeing a huge amount of development work before
>people started adding EC support to it, was it? Other than keeping it
>up to date with OpenSSL releases, of course...

Yep…

>I don't anticipate that it would be a large maintenance burden.

Michal would be the right person to comment on this, but I think I agree.

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Ubsec and Chil engines

David Woodhouse-7
In reply to this post by Sander Temme
On Sat, 2016-02-20 at 12:40 -0800, Sander Temme wrote:
> However, I’m intrigued by the notion of a PKCS#11 Engine in OpenSSL:
> it’s a standard (an OASIS standard now); it’s fairly fully featured;
> everyone in the industry supports it including Thales; and you can
> build a program that calls it without needing a vendor SDK, because
> there are standard headers and a well defined way to get to the entry
> points.  If we can come up with a way to pick a PKCS#11 slot and log
> into it that makes sense (e.g. not by poking PINs into a system wide
> config file etc.) then I think we’d have a winner.

OK, let's explore that. Let's assume, purely for the sake of this
discussion, that we ditch the engine from OpenSSL 1.1 and go *purely*
with a solution based around the existing engine_pkcs11.

From your point of view, what problems are there with that scenario?

You talk about "a way to pick a PKCS#11 slot and log into it"... that's
basically handled by RFC7512, isn't it? The PKCS#11 URI gives us a
standard way to specify not only the slot but also the object therein.
It *also* allows a pin-value attribute to be encoded within the URI if
you want to do that.

If you don't want to encode the PIN, it can be requested at runtime via
a UI_METHOD that you provide. I see the Chil engine also supports an
alternative callback function... does that really provide any more
functionality than your own UI_METHOD does? We could potentially add
that... if we must.

Are there any (other) gaps in required functionality?

Note that engine_pkcs11 doesn't currently support the ?module-path=
query attribute. The code flow of the engine doesn't make that trivial,
since we initialise the engine (and load the provider module) first and
only *later* do we get given a URI to deal with. It's not beyond the
wit of man to fix that though, if we need to.

We *haven't* needed to care about it so far, though. General-purpose
builds (such as building packages for Linux distributions) tend to just
use p11-kit-proxy.so as the default module. That just makes us obey the
*system* configuration for which PKCS#11 modules should be visible to
which applications. And special-purpose use cases can specify a module
in advance when loading the engine. Anyone migrating code which
explicitly uses the Chil engine to engine_pkcs11 would be able to
specify the appropriate module path when loading the engine.

For sanely maintained Linux distributions at least, I want to get to a
point where *any* application which can take certs/keys from a file,
should *also* accept a PKCS#11 URI in place of a file name and should
just work. The Fedora packaging guidelines already say that this SHOULD
be the case, FWIW.

> What I would like to see though is for such a PKCS#11 Engine to be
> part of OpenSSL proper,

Yeah yeah, but not for 1.1. Some of us are hoping to fix that for 1.2
(and not necessarily as an ENGINE but more by having PKCS#11 support
properly integrated). We have agreement from copyright-holders of most
of the existing engine (and libp11, where most of the *functionality*
lies) to relicense it and include it in OpenSSL.

--
David Woodhouse                            Open Source Technology Centre
[hidden email]                              Intel Corporation


--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

smime.p7s (7K) Download Attachment
12