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