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 w
>>> 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
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
Forwarded Message
From: Robert Relyea
To: Nikos Mavrogiannopoulos
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 wrote:
> On Mon, 2016-02-22 at 15:08 +0100, Jaros
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
On Mon, 2016-02-22 at 15:59 +, Blumenthal, Uri - 0553 - MITLL wrote:
> On 2/22/16, 6:12 , "openssl-dev on behalf of David Woodhouse"
> 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
> >
On Mon, 2016-02-22 at 14:46 +, 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
On Mon, 2016-02-22 at 15:08 +0100, Jaroslav Imrich wrote:
> On 22 February 2016 at 11:16, Nikos Mavrogiannopoulos 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.
>
On 2/22/16, 6:12 , "openssl-dev on behalf of David Woodhouse"
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 open
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 SS
> 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 fu
On 22 February 2016 at 11:16, Nikos Mavrogiannopoulos
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
On Mon, 2016-02-22 at 12:52 +0100, Richard Levitte wrote:
>
> 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 i
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 O
On Sat, 2016-02-20 at 22:55 +0100, Richard Levitte wrote:
>
> 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 softwar
On Fri, 2016-02-19 at 15:53 +0100, Nikos Mavrogiannopoulos wrote:
> On Fri, 2016-02-19 at 13:12 +, Matt Caswell wrote:
>
> > As far as I know there are some customers using the Chil engine
> > > with
> > > RHEL (openssl-1.0.1).
> >
> > How do you feel about the engine being spun out into a s
On Sat, 2016-02-20 at 23:34 +0100, Jaroslav Imrich wrote:
> 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
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 with
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
> 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). H
oulos
Sent: Friday, February 19, 2016 09:53
To: openssl-dev@openssl.org
Reply To: openssl-dev@openssl.org
Subject: Re: [openssl-dev] Ubsec and Chil engines
On Fri, 2016-02-19 at 13:12 +, Matt Caswell wrote:
> As far as I know there are some customers using the Chil engine
> > with
>
On Fri, 2016-02-19 at 13:12 +, Matt Caswell wrote:
> As far as I know there are some customers using the Chil engine
> > with
> > RHEL (openssl-1.0.1).
>
> How do you feel about the engine being spun out into a separate repo?
> That of course assumes that a volunteer can be found to maintain
"Salz, Rich" skrev: (19 februari 2016 15:07:42 CET)
>
>> 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
>separ
> 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 GOS
Matt Caswell skrev: (19 februari 2016 14:12:28 CET)
>
>
>On 19/02/16 13:03, Tomas Mraz wrote:
>> On Pá, 2016-02-19 at 11:31 +, Matt Caswell wrote:
>>
>>
>>> 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
On 19/02/16 13:11, Jaroslav Imrich wrote:
> 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.
>
Gr
On 19/02/16 13:03, Tomas Mraz wrote:
> On Pá, 2016-02-19 at 11:31 +, Matt Caswell wrote:
>
>
>> 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 m
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-dev mailing list
To unsubscribe: https:
On Pá, 2016-02-19 at 11:31 +, Matt Caswell wrote:
> 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 i
Hi all
The ubsec and chil engines are currently disabled in 1.1.0 and do not build.
As far as ubsec is concerned I understand that this is an engine for
broadcom cards. There has been very little activity with this engine
since it was first introduced. Google brings up some very old historic
refe
30 matches
Mail list logo
