On Tue, 2016-12-13 at 16:49 -0800, James Bottomley wrote: > > So the proposal is to have a TPM specific value for PrivateKeyAlgorithm > (which would have to be proposed as an OID) and use PrivateKeyInfo for > the key? That could be made to work.
Right. > The slight fly in the ointment that's worrying me is that I need a key > format that works for pkcs#11 tokens as well. The problem here is that > TPM keys don't have an id or a label and that's pretty much a > requirement of using a pkcs#11 token, so the pkcs#11 code has to be > able to set these attributes on the key files. I was originally > thinking of putting them into the PEM header with a pkcs11- prefix. I > suppose I can do the same with the attributes and some manufactured OID > prefix with the CKA_ parameters we're interested in as a suffix but > it's messy. Hm, this seems odd. If something is stored in a file then exposing it through PKCS#11 doesn't make sense at all. Do not attempt to use PKCS#11 for any file access. Seriously, if you have any doubts about that at all, go read nss-pem and ponder its operation. Then drink until you've forgotten most of it, but remember that PKCS#11 isn't to be used for accessing stuff that you have in a file. PKCS#11 can sanely be used for keys which are persistently stored *in* the TPM storage, which *do* have a UUID which can be used as CKA_ID. (Or maybe as CKA_LABEL since CKA_ID really SHOULD be the pubkey hash, if we can manage that). If you're talking about a PKCS#11 token which has its *own* storage of wrapped keys, then sure — you can keep whatever metadata you like. But you don't need that to be part of the PKCS#8 standard format. In fact if you want this you're probably better off extending SoftHSM to stored wrapped keys and use the TPM for operating them. -- dwmw2
smime.p7s
Description: S/MIME cryptographic signature
-- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
