Re: [openssl-users] [openssl-dev] Ubsec and Chil engines

[Sander Temme]

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  wrote:
> 
> In message 
> <347004c001fd430aadadceac908e6...@ustx2ex-dag1mb1.msg.corp.akamai.com> on 
> Mon, 22 Feb 2016 14:46:28 +, "Salz, Rich"  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 levi...@openssl.org
> OpenSSL Project http://www.openssl.org/~levitte/
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] [openssl-dev] Ubsec and Chil engines

[Richard Levitte]

In message 
<347004c001fd430aadadceac908e6...@ustx2ex-dag1mb1.msg.corp.akamai.com> on Mon, 
22 Feb 2016 14:46:28 +, "Salz, Rich"  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 levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] [openssl-dev] Ubsec and Chil engines

[Salz, Rich]

> 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.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] [openssl-dev] Ubsec and Chil engines

[Richard Levitte]

In message <1456140741.4735.272.ca...@infradead.org> on Mon, 22 Feb 2016 
11:32:21 +, David Woodhouse  said:

dwmw2> On Sat, 2016-02-20 at 22:55 +0100, Richard Levitte wrote:
dwmw2> > 
dwmw2> > sander> What I would like to see though is for such a PKCS#11 Engine
dwmw2> > sander> to be part of OpenSSL proper, so that our customers and
dwmw2> > sander> everyone else’s don’t have to go hunt hither and yon for bits
dwmw2> > sander> and bobs of software in order to make their hardware kit work
dwmw2> > sander> with OpenSSL.  How would OpenSSL obtain a PKCS#11 Engine to
dwmw2> > sander> include in its distribution?
dwmw2> > 
dwmw2> > I'm not sure if this is a problem specifically for OpenSSL to solve,
dwmw2> > or if it is a packager problem. 
dwmw2> 
dwmw2> I touched on this in a message a few minutes ago, but I *definitely*
dwmw2> think it's the former.
dwmw2> 
dwmw2> If we integrate the support natively into OpenSSL, then PKCS#11 URIs
dwmw2> (see RFC7512) can be first-class citizens throughout the crypto and SSL
dwmw2> APIs. Any function which takes a filename for a cert or key should also
dwmw2> accept¹ a PKCS#11 URI.
dwmw2> 
dwmw2> Then we can also use PKCS#11 for the trust database, which allows us to
dwmw2> properly handle the trusted *purposes* in ways that a flat file
dwmw2> doesn't. And that flat file is now *exported* from the p11-kit-trust
dwmw2> token purely for the benefit of OpenSSL, which it would be nice to stop
dwmw2> doing.
dwmw2> 
dwmw2> I am happy to work on this.

That takes me back to crypto/store, which is currently removed in
master but which I have a rework of in a branch, which is meant to
solve this exact problem, but without being exclusively tied to
PKCS#11.  The design is to have it work with engine backends, and a
PKCS#11 engine that's part of OpenSSL would fit that bill, so to say.

Shall we talk?

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] [openssl-dev] Ubsec and Chil engines

[Jaroslav Imrich]

On 20 February 2016 at 21:40, 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.
>

Let's not forget that CHIL provides one very unique feature - forked
process keeps the authentication state of its parent and can access HSM
keys if its parent was authenticated. PKCS#11 specification prohibits such
behavior (PKCS#11 v2.20 chapter 6.6.1) and because of that PKCS#11 based
engine couldn't fully replace CHIL engine.

Regards, Jaroslav
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] [openssl-dev] Ubsec and Chil engines

[Richard Levitte]

In message <5b8f45ea-5867-4832-916a-6b31a323a...@temme.net> on Sat, 20 Feb 2016 
12:40:38 -0800, Sander Temme  said:

sander> 
sander> > On Feb 19, 2016, at 3:31 AM, Matt Caswell  wrote:
sander> 
sander> OK that made our support lines blow up so yes there is interest.
sander> 
sander> Disclaimer: I work for Thales but do not speak for Thales.
sander> 
sander> > So it seems that for chil there may possibly be some rare use (but 
even
sander> > the most recent evidence is 4 years old). However the OpenSSL dev team
sander> > do not have access to this hardware to maintain the engine and (as 
noted
sander> > above) this is currently not building in 1.1.0.
sander> 
sander> I think (again, personal impression) that this is one of those
sander> sleeper integrations that a lot of people use but doesn’t get
sander> on the radar a whole lot. Using openssl is by far the easiest
sander> way to get the nShield HSM to do something with protected
sander> keys… as long as those are RSA keys.  Pair that with existing
sander> application integrations like Apache, OpenSSH, etc. I know of
sander> a number of customers and partners, none of whom I am at
sander> liberty to discuss (although they might speak up for
sander> themselves), who use OpenSSL with nShield for various
sander> applications.

Oh, nShield?  Back when I was playing with e_chil.c, it was nCipher.
But, no matter really...

sander> So it’s not dead.  What it does, it does very well.  If
sander> anything, the lack of visible activity may indicate how easy
sander> CHIL is to use and support.

The trouble is that we can't verify that.  We don't have the hardware
or the expertise.  Even the few of us that got to play with a nCipher
box 15+ years ago don't have that around any more.  So there's that
pile of code that no one dares to touch because we have no idea what
the effects might be and have no way of testing that.

With all that in mind, I've a question back to you...  wouldn't it be
more productive if Thales let an OpenSSL engine, built as a DSO,
accompany the hardware?  Considering you are much closer to the
hardware and the expertise, it seems a bit more appropriate, doesn't
it?

sander> What I would like to see though is for such a PKCS#11 Engine
sander> to be part of OpenSSL proper, so that our customers and
sander> everyone else’s don’t have to go hunt hither and yon for bits
sander> and bobs of software in order to make their hardware kit work
sander> with OpenSSL.  How would OpenSSL obtain a PKCS#11 Engine to
sander> include in its distribution?

I'm not sure if this is a problem specifically for OpenSSL to solve,
or if it is a packager problem.  Sometimes, the border between the two
might be blurry, but...  If OpenSSL is to "obtain" a PKCS#11 engine,
it would probably be by writing one.  It would be far easier, though,
if someone would package the already existing engine_pkcs11 with
OpenSSL (that packaging doesn't have to be done by the OpenSSL team),
*or* with hardware distributions.

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] [openssl-dev] Ubsec and Chil engines

[Sander Temme]

> On Feb 19, 2016, at 3:31 AM, Matt Caswell  wrote:

OK that made our support lines blow up so yes there is interest.

Disclaimer: I work for Thales but do not speak for Thales.

> So it seems that for chil there may possibly be some rare use (but even
> the most recent evidence is 4 years old). However the OpenSSL dev team
> do not have access to this hardware to maintain the engine and (as noted
> above) this is currently not building in 1.1.0.

I think (again, personal impression) that this is one of those sleeper 
integrations that a lot of people use but doesn’t get on the radar a whole lot. 
Using openssl is by far the easiest way to get the nShield HSM to do something 
with protected keys… as long as those are RSA keys.  Pair that with existing 
application integrations like Apache, OpenSSH, etc. I know of a number of 
customers and partners, none of whom I am at liberty to discuss (although they 
might speak up for themselves), who use OpenSSL with nShield for various 
applications.

So it’s not dead.  What it does, it does very well.  If anything, the lack of 
visible activity may indicate how easy CHIL is to use and support.

> In both cases I would like to remove these engines from 1.1.0. I'd like
> to hear from the community if there is any active use of these. One
> option if there is found to be some small scale use is to spin out the
> engine into a separately managed repo (as has happened recently with the
> GOST engine).
> 
> If I don't hear from anyone I will remove these.

Ehm.  Let’s talk about this.  As I noted above, a lot of our valued customers 
may depend on this even thought they might not know or may have forgotten about 
it.  From your October 28 commit (29e7a56d), it seems that what broke us was 
when the bn structure went opaque… I see only two lines in e_chil.c that depend 
on the internal structure of bn so that should be addressable.  We’d like to do 
some more things to this Engine, like more key types and, yes, those dynamic 
locks should go away, which requires some surgery to the stuff underneath but 
nothing major.  All the platforms we run on now have good locking.  And, Rich, 
I indeed have had those locks on my guilty conscience for all this time but not 
found any round tuits.

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.

What I would like to see though is for such a PKCS#11 Engine to be part of 
OpenSSL proper, so that our customers and everyone else’s don’t have to go hunt 
hither and yon for bits and bobs of software in order to make their hardware 
kit work with OpenSSL.  How would OpenSSL obtain a PKCS#11 Engine to include in 
its distribution?

Thanks,

S.

--
san...@temme.net  http://www.temme.net/sander/
PGP FP: BCD1 6D2C 8906 C48A 540E  253E 94D3 36A3 6D15 930A





signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] [openssl-dev] Ubsec and Chil engines

[Salz, Rich]

> In both cases I would like to remove these engines from 1.1.0. I'd like to 
> hear
> from the community if there is any active use of these. One option if there is
> found to be some small scale use is to spin out the engine into a separately
> managed repo (as has happened recently with the GOST engine).

Please do.  I know Sander was interested in updating CHIL but never found time.

That also removes the last remaining need for "dynamic locks"  huzzah
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] [openssl-dev] Ubsec and Chil engines

[Jaroslav Imrich]

Hello Matt,

If I don't hear from anyone I will remove these.
>

I can confirm that CHIL engine is actively used with OpenSSL 1.0.* by the
owners of nCipher/THALES nShield HSMs.

I have notified vendor support about this thread.

Regards, Jaroslav
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users