On Tue, Dec 13, 2016, 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.

If you go the PKCS#8 route then it would presumably be the unencrypted form.
One way to handle things would be to assign an OID for TPM and have an ASN.1
module unwrap the thing and return an EVP_PKEY structure.

That would work with any version of OpenSSL without modification if the ENGINE

Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Reply via email to