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@xxxxxxxxx Intel Corporation
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
