On Fri, 2020-01-31 at 18:43 +0100, Jakub Jelen wrote: > On Thu, 2020-01-30 at 16:24 +0100, James Bottomley wrote: > > Engine keys are keys whose file format is understood by a specific > > engine rather than by openssl itself. Since these keys are file > > based, the pkcs11 interface isn't appropriate for them because they > > don't actually represent tokens. > > There is already tpm2-pkcs11 module which addresses the same use case > in a standard way for TPM2: > > https://github.com/tpm2-software/tpm2-pkcs11 Well, there's no need for anything that specific. This project can provide a pkcs11 provider for any engine: https://git.kernel.org/pub/scm/linux/kernel/git/jejb/openssl-pkcs11-export.git I wrote it to make engines work with NSS since there are some things that don't have a pkcs11 module. But the more fundamental problem is pkcs11 is not a good interface for file based keys ... as I think you know, otherwise the openssl U2F support would be implemented via pkcs11. pkcs11 is a great interface if the key resides within the token, as it does for a lot of them because it's got a search function and a URI expression for the token (if you use p11-kit). However, when the key is file based it's not good because the URI doesn't have an expression for the file location meaning you have to add extra configuration glue to get the pkcs11 emulation to work. Essentially the glue tells the engine where to find the key files and how to export them. Fundamentally the ssh user experience is file based: you have a public and a private key file in the .ssh directory that are your identity. The engine paradigm matches that exactly, so it's far easier for consumers simply to convert the openssl private key to an engine one and use it in the same way than it is for them to construct the two layers of indirection necessary to use the key via a pkcs11 token interface. It's also consonant with our job of making security simpler for the users not more complex. > I do not think all the applications that want support for > TPM2/engines should need to implement support for engines. Well, yes, what should happen is that openssl should try all the import formats it knows about instead of having one API for PEM, one for DER and one for engines ... however, I lost that battle a long time ago. > Especially when the engines are to be replaced by a new providers > interface in future OpenSSL releases: > > https://www.openssl.org/docs/OpenSSLStrategicArchitecture.html A provider is simply a fancy name for an engine, there's no huge architectural difference. I and several other people who lost the "why three different file loading interfaces" battle the last time around will be nudging openssl to couple the provider and the store, so that if a provider exists, the key file gets loaded through a single API ... if that happens, the engine code in openssl can go away, assuming we win the battle this time around ... but I wouldn't rule out that the engine file API will get reborn as the provider file API and the same problem will exist. James _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev