On Wed, 2016-12-14 at 18:03 -0500, James Bottomley wrote:
> > I think we're talking about two different things. What I mean is that
> > a given application shall never have to deal with files and PKCS#11
> > for a given single object.
>
> Sure (as in I thought that went without saying).
If only
On Wed, 2016-12-14 at 17:05 +, David Woodhouse wrote:
> On Wed, 2016-12-14 at 06:58 -0800, James Bottomley wrote:
> > > Hm, this seems odd. If something is stored in a file then
> > > exposing it through PKCS#11 doesn't make sense at all. Do not
> > > attempt to use PKCS#11 for any file acces
On Wed, 2016-12-14 at 06:58 -0800, James Bottomley wrote:
> > Hm, this seems odd. If something is stored in a file then exposing it
> > through PKCS#11 doesn't make sense at all. Do not attempt to use
> > PKCS#11 for any file access.
>
> OK, so the horse has already left the stable on that one wit
On Wed, 2016-12-14 at 09:07 +, David Woodhouse wrote:
> On Tue, 2016-12-13 at 16:49 -0800, James Bottomley wrote:
> >
> > So the proposal is to have a TPM specific value for
> > PrivateKeyAlgorithm (which would have to be proposed as an OID) and
> > use PrivateKeyInfo for the key? That coul
On Tue, 2016-12-13 at 16:49 -0800, James Bottomley wrote:
>
> So the proposal is to have a TPM specific value for PrivateKeyAlgorithm
> (which would have to be proposed as an OID) and use PrivateKeyInfo for
> the key? That could be made to work.
Right.
> The slight fly in the ointment that's wo
On Tue, 2016-12-13 at 22:28 +, David Woodhouse wrote:
> On Tue, 2016-12-13 at 13:09 +, Dr. Stephen Henson wrote:
> > The reason for that is that the PEM forms which contain
> > the key algorithm in the PEM header were considered legacy types
> > and new methods should use PKCS#8 instead. S
On Tue, Dec 13, 2016, David Woodhouse wrote:
> On Tue, 2016-12-13 at 13:09 +, Dr. Stephen Henson wrote:
> > The reason for that is that the PEM forms which contain
> > the key algorithm in the PEM header were considered legacy types and new
> > methods
> > should use PKCS#8 instead. So there
On Tue, 2016-12-13 at 13:09 +, Dr. Stephen Henson wrote:
> The reason for that is that the PEM forms which contain
> the key algorithm in the PEM header were considered legacy types and new
> methods
> should use PKCS#8 instead. So there was no way to set legacy PEM decoders to
> discourage th
On Tue, Dec 13, 2016, Dr. Stephen Henson wrote:
>
> So if we wanted to go down this route all that is needed to get a form of this
> functionality is a function to set the PEM decoder in EVP_PKEY_ASN1_METHOD.
>
Note however that this currently assumes the data between the PEM headers is
base64
On Wed, Nov 30, 2016, James Bottomley wrote:
> One of the principle problems of using TPM based keys is that there's
> no easy way of integrating them with standard file based keys. This
> proposal adds a generic method for handling file based engine keys that
> can be loaded as PEM files. Integ
On Fri, 2016-12-02 at 08:03 -0800, James Bottomley wrote:
> > Most likely (and hopefully) the latter keys will be handled over
> > PKCS#11 rather than directly.
>
> I have reservations about scaling pkcs11 into a multi-tenant
> environment, but I agree, in principle it is possible. I'm looking
On Thu, 2016-12-01 at 12:49 +0100, Nikos Mavrogiannopoulos wrote:
> On Wed, 2016-11-30 at 13:59 -0800, James Bottomley wrote:
>
> > > > The point here is that because there's a pem file
> > > representation of the
> > > > key, it can be used anywhere a PEM file can be *without*
> > > havin
On Wed, 2016-11-30 at 13:59 -0800, James Bottomley wrote:
> > > The point here is that because there's a pem file
> > representation of the
> > > key, it can be used anywhere a PEM file can be *without*
> > having
> > to tell
> > > openssl what the engine is (the PEM guards being uniqu
On Wed, 2016-11-30 at 21:41 +, Blumenthal, Uri - 0553 - MITLL
wrote:
> >> So why is it better to say “…engine –key
> /some/weird/path/weird
> >> -file.pem” than “…engine –key pkcs11:id=02” (or such)?
> >
> > There appears to be some confusion here. pkcs11 is a
> representation
>> So why is it better to say “…engine –key /some/weird/path/weird
>> -file.pem” than “…engine –key pkcs11:id=02” (or such)?
>
> There appears to be some confusion here. pkcs11 is a representation
> for defined tokens.
Well, I did not mean *specifically* pkcs11 – just as an e
On Wed, 2016-11-30 at 21:18 +, Blumenthal, Uri - 0553 - MITLL
wrote:
> On 11/30/16, 10:24 AM, "openssl-dev on behalf of James Bottomley" <
> openssl-dev-boun...@openssl.org on behalf of
> james.bottom...@hansenpartnership.com> wrote:
>
> > One of the principle problems of using TPM based
On 11/30/16, 10:24 AM, "openssl-dev on behalf of James Bottomley"
wrote:
> One of the principle problems of using TPM based keys is that there's
> no easy way of integrating them with standard file based keys.
Why should token- and/or TPM-based keys be integrated with file-based keys?
17 matches
Mail list logo