The reason this comes about is because we already have a standard form for TPM 1.2 keys here:
http://david.woodhou.se/draft-woodhouse-cert-best-practice.html#ident-tpm However, since I'm working on TPM2 enabling for openssl and gnutls, I need to come up with a new key format because TPM2 requires some extra parameters and the original TSS KEY BLOB, being a single ASN1_OCTET_STRING isn't expandable. As a digression, the extra parameters that TPM2 needs are: 1. A public key blob. In TPM12 the key complex was a joint public/private part. In TPM2, the public and private key structures have variable length and are supplied separately. 2. a boolean for emptyAuth. In TPM12 there's a way to tell if a structure has no authorization. In TPM2 there's no such thing as no authorization, but there's a conventional empty authorization to replace it but no way of querying whether any given key is using it, so we need to know explicitly whether to prompt for a password or not. 3. There are different forms a TPM private key could be in. One is symmetrically encrypted with a TPM private key, which makes it loadable, meaning it must be produced on the TPM itself and the other is asymmetrically encrypted meaning it can be produced away from the TPM but must be imported before being loaded. I think there's value in having a universal structure for the key representations, so I'm proposing an ASN1 representation that will work for both TPM1.2 and TPM2 keys. I'd also like it to be self describing, so I think we should use an OID as the initial parameter of the sequence. With that, I think the format that works is TPMKey ::= SEQUENCE { type OBJECT IDENTIFIER version [0] IMPLICIT INTEGER OPTIONAL emptyAuth [1] IMPLICIT BOOLEAN OPTIONAL parent [2] IMPLICIT INTEGER OPTIONAL publicKey [3] IMPLICIT OCTET STRING OPTIONAL privateKey OCTET STRING } Where TPM12 keys would have a TPM12Key type and use no optional fields (meaning only privateKey) and TPM2 keys would have type TPM2LoadableKey or TPM2ImportableKey type and then make use of all the optional fields (except version). Version is there for future expansion, but is unused in the initial incarnation. I'm torn on where to get the OIDs from. Since this is a TPM key, it might make sense to use the TCG OID (2.23.133) and just add something they haven't already used, like 10 for key formats, or we could go with a pkcs OID (1.2.840.113549.1) If we can agree on this, we can update David's document and make it a formal RFC. Thoughts? James -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
