On Fri, 2016-12-23 at 21:12 +0100, Richard Levitte wrote:
> 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-pr
> actice.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.
Thanks. After playing more I think I'd like to make the tags explicit
rather than implicit so I can see the contents easily with asn1parse
(and we're not in any way pressed for space, which is the usual reason
for implicit tags).
> 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)
> }
Because what OID to use is part of the discussion. Perhaps I wasn't
clear about what I want: the OID needs to identify what the structure
describes, so one OID for each of the three key types, so it would have
a prefix either in the TCG or pkcs space (or something else if that's
what we agree), then three OID postfixes.
> TPMKey ::= SEQUENCE {
> type OBJECT IDENTIFIER -- always TCG
> version [0] INTEGER { v1_2(0), v2(1) } DEFAULT v1_2
Version, I'm envisaging is for expansion of the structure in a
compatible way. For TPM2 keys, I think we're going to need additional
policy descriptors eventually when people start using a policy to
authorise instead of an authorisation value. We'd use the version
number to indicate a future expanded structure.
So the OID identifies the object structure and version is for
versioning the actual structure.
James
> 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
