On Wed, 2015-10-28 at 00:35 +0100, Stephan Mueller wrote: > Am Mittwoch, 28. Oktober 2015, 08:15:16 schrieb David Woodhouse: > > Hi David, > > > > Absolutely. The interface needs to support *both*. > > > > I've spent a lot of time chasing through userspace stacks, fixing > > broken assumptions that we will *always* have the actual key material > > in a file — and making libraries and applications accept PKCS#11 URIs > > referring to keys in hardware as well as filenames. > > > > I am violently opposed to exposing an API from the kernel which makes > > that *same* fundamental mistake, and ties its users to using *only* > > software keys. > > > > FROM THE BEGINNING, users of this new API should be able to cope with > > the fact that they might not *have* the key material, and that they > > might simply be referring to a key which exists elsewhere. Such as in > > the TPM, or within an SGX software enclave. > > Albeit that all sounds like the crown jewel, how do you propose that shall > happen? > > Assume that you have a web server that has a pub and priv key in its current > configuration -- I guess that is the vast majority of configs. > > Can you please elaborate how the process for such a web server shall really > work? 1. Create a kernel-side key. 2. Use it. That may require adding an API similar to the one you're proposing, but working with kernel keys instead of directly with akcipher. Or perhaps the key subsystem can already offer what you need in userspace. David? -- dwmw2
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
