Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1399919

Re: [RFC PATCH 2/8] KEYS: Provide keyctls to drive the new key type ops for asymmetric keys [ver 3]

Show all headers | View raw

[Multipart message — attachments visible in raw view] - view raw

On Wed, 2016-05-11 at 15:17 -0700, Mat Martineau wrote:
> 
> On Wed, 11 May 2016, David Howells wrote:
> 
> > diff --git a/Documentation/security/keys.txt b/Documentation/security/keys.txt
> > index ca72b70a24b9..01c2ae28a8c0 100644
> > --- a/Documentation/security/keys.txt
> > +++ b/Documentation/security/keys.txt
> > +     If the key needs to be unlocked with a password, a logon-type key that
> > +     holds the password may be given as the password argument
> ...
> > +     If the key must be unlocked with a password before it can be used,
> > +     password_id should point to a logon-type key that holds this.
> 
> It should be noted that the password_id should be 0 if no password is to 
> be used.

Hm, I would like to properly explore the use cases for these passwords,
before any API is set in stone.

To start with, I'll insist quite strongly that we should never be
passing an encrypted key into the kernel alongside the password needed
to decrypt it. We should let userspace do that gruntwork, and pass in a
canonical DER PKCS#8 (or PKCS#1) blob. As I said before, the other way
lies madness, and requests to support all the obscure formats that keys
are stored in.

So where *might* we want a password... mostly for things like TPM and
other crypto hardware (USB tokens, HSMs). And the usage model there is
normally that the password isn't tied to the *key*, it's a password or
PIN to unlock the *device*.

So I'm not quite sure this 'password_id' makes much sense at all...
unless the idea is that you load the (encrypted) key in advance and
then request the password *later* on demand, in order to use it? Is
that something we really need to support?

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

[RFC PATCH 0/8] KEYS: keyctl operations for asymmetric keys [ver 3] David Howells <dhowells@redhat.com> - 2016-05-11 16:30 +0200
  [RFC PATCH 3/8] KEYS: Provide missing asymmetric key subops for new  key type ops [ver 3] David Howells <dhowells@redhat.com> - 2016-05-11 16:30 +0200
  [RFC PATCH 2/8] KEYS: Provide keyctls to drive the new key type ops  for asymmetric keys [ver 3] David Howells <dhowells@redhat.com> - 2016-05-11 16:30 +0200
    Re: [RFC PATCH 2/8] KEYS: Provide keyctls to drive the new key type  ops for asymmetric keys [ver 3] Mat Martineau <mathew.j.martineau@linux.intel.com> - 2016-05-12 00:20 +0200
      Re: [RFC PATCH 2/8] KEYS: Provide keyctls to drive the new key type ops for asymmetric keys [ver 3] David Howells <dhowells@redhat.com> - 2016-05-12 12:20 +0200
      Re: [RFC PATCH 2/8] KEYS: Provide keyctls to drive the new key type  ops for asymmetric keys [ver 3] David Woodhouse <dwmw2@infradead.org> - 2016-05-12 13:10 +0200
  [RFC PATCH 7/8] KEYS: Implement encrypt,  decrypt and sign for software asymmetric key [ver 3] David Howells <dhowells@redhat.com> - 2016-05-11 16:30 +0200
  [RFC PATCH 5/8] KEYS: Provide software public key query function  [ver 3] David Howells <dhowells@redhat.com> - 2016-05-11 16:30 +0200
    Re: [RFC PATCH 5/8] KEYS: Provide software public key query function  [ver 3] Mat Martineau <mathew.j.martineau@linux.intel.com> - 2016-05-12 02:00 +0200
      Re: [RFC PATCH 5/8] KEYS: Provide software public key query function  [ver 3] Tadeusz Struk <tstruk@gmail.com> - 2016-05-12 02:20 +0200
      Re: [RFC PATCH 5/8] KEYS: Provide software public key query function [ver 3] David Howells <dhowells@redhat.com> - 2016-05-12 12:20 +0200
        Re: [RFC PATCH 5/8] KEYS: Provide software public key query function  [ver 3] Mat Martineau <mathew.j.martineau@linux.intel.com> - 2016-05-12 19:10 +0200
  [RFC PATCH 1/8] KEYS: Provide key type operations for asymmetric  key ops [ver 3] David Howells <dhowells@redhat.com> - 2016-05-11 16:30 +0200
  [RFC PATCH 8/8] KEYS: Implement PKCS#8 RSA Private Key parser [ver  3] David Howells <dhowells@redhat.com> - 2016-05-11 16:30 +0200
    Re: [RFC PATCH 8/8] KEYS: Implement PKCS#8 RSA Private Key parser  [ver 3] David Woodhouse <dwmw2@infradead.org> - 2016-05-11 21:20 +0200
    Re: [RFC PATCH 8/8] KEYS: Implement PKCS#8 RSA Private Key parser  [ver 3] Mat Martineau <mathew.j.martineau@linux.intel.com> - 2016-05-12 02:20 +0200
      Re: [RFC PATCH 8/8] KEYS: Implement PKCS#8 RSA Private Key parser [ver 3] David Howells <dhowells@redhat.com> - 2016-05-12 12:30 +0200
  [RFC PATCH 4/8] KEYS: Make the X.509 and PKCS7 parsers supply the  sig encoding type [ver 3] David Howells <dhowells@redhat.com> - 2016-05-11 16:30 +0200
  [RFC PATCH 6/8] KEYS: Allow the public_key struct to hold a private  key [ver 3] David Howells <dhowells@redhat.com> - 2016-05-11 16:30 +0200

csiph-web