On Tue, 2016-12-13 at 22:28 +0000, David Woodhouse wrote: > On Tue, 2016-12-13 at 13:09 +0000, Dr. Stephen Henson wrote: > > The reason for that is that the PEM forms which contain > > the key algorithm in the PEM header were considered legacy types > > and new methods should use PKCS#8 instead. So there was no way to > > set legacy PEM decoders to discourage their use. > > > > In this case the reason is different: the header doesn't contain > > the algorithm type but a string which an ENGINE can handle. So it > > isn't a "legacy format" but a custom one. > > > > So if we wanted to go down this route all that is needed to get a > > form of this functionality is a function to set the PEM decoder in > > EVP_PKEY_ASN1_METHOD. > > I am not entirely averse to the idea of saying that TPM, at least as > of 2.0, should have a wrapped-key storage format which is based in > PKCS#8 rather than doing its own thing.
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. 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. James
smime.p7s
Description: S/MIME cryptographic signature
-- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
