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 at > trying to do it better for TPM now (well, it's the next thing to get to > on my list).
There are two problems with PKCS#11 and TPM. Firstly, PKCS#11 only supports one PIN per PKCS#11 provider. If each key can have its *own* PIN, that doesn't work so well. You can play deprecated tricks and have a separate slot for each key, but that quickly gets horrid, and more so when you consider the second problem... Secondly, wrapped keys don't actually exist in the TPM so there's no 'URI' that you can refer to them by; they are ephemeral. The encrypted key is actually *in* the PEM file, and gets loaded into the TPM for it to decrypt and use. So to cope with this through PKCS#11 you'd need some kind of nasty hack where it loads the PEM file and a new token magically "hotplugs" into existence. We already have something that's *almost* this horrid, with the nss-pem abomination that NSS uses to load PEM files; you call the C_CreateObject() method using an object 'label' which is actually a file name.... it's vile, and it's not really a model we want to follow. I think we really do need native support for loading these PEM files, and not to attempt to make it work through PKCS#11. -- dwmw2
smime.p7s
Description: S/MIME cryptographic signature
-- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
