[gnutls-devel] Proposal for the ASN.1 form of TPM1.2 and TPM2 keys

[James Bottomley]

On Mon, 2016-12-26 at 21:13 +0100, Nikos Mavrogianopoulos wrote:
> My comment was on the claim of extendability of the format which as I
> explained it is simply not true. As for example I already gave the
> key usage extension. I am fine however with a non extendable format
> as you proposed. 

OK, so I think the version is now superfluous, since if anything gets
added it can be recognised by the tag and things not ready to parse
that tag can reject it.

That makes the final form

 TPMKey ::= SEQUENCE {
	type		OBJECT IDENTIFIER
	emptyAuth	[0] EXPLICIT BOOLEAN OPTIONAL
	parent		[1] EXPLICIT INTEGER OPTIONAL
	pubkey		[2] EXPLICIT OCTET STRING OPTIONAL
	privkey		OCTET STRING
 }

I'll code the v2 patch using this form.

James

> On December 26, 2016 7:13:40 PM GMT+01:00, James Bottomley <
> James.Bottomley at HansenPartnership.com> wrote:
> > On Mon, 2016-12-26 at 08:18 +0100, Nikos Mavrogianopoulos wrote:
> > > I'd like both backwards and forward compatibility actually,
> > > exactly
> > > like x509. If an informational field is added like the key usage
> > > that
> > > I mentioned, I doubt you'd like all the previous consumers
> > > incompatible.
> > 
> > OK, so there's a fundamental difference between a v3 X509
> > certificate
> > and a TPM key: An X509 certificate is a signature over a set of v1
> > TBS
> > data, a public key and a bundle of attributes.  To verify the
> > certificate or extract the key, you don't need to know what the
> > attributes are, so you can still "use" the certificate in that
> > form. 
> > However, you can't get the v1 tool to obey the v3 constraints on
> > the
> > certificate because it doesn't understand them.
> > 
> > The ASN.1 description of a TPM key contains the actual binary
> > representation of the key plus a set of information which explains
> > to
> > the consuming code how to use the key.  Since I can't think of a
> > way of
> > making use of the key without understanding all of the information
> > about how to use it, I think it is beneficial that v1 consumers
> > don't
> > try to use v2 key information because the resulting failure will
> > excite
> > the TPM's dictionary attack protection.
> > 
> > I gave an example of one such extension: policy authorisations, but
> > they're definitely of the "if you don't understand these, you can't
> > use
> > the key" variety.  Perhaps if you can give an example of a
> > potentially
> > compatible extensions it would help me to see your point and give
> > us a
> > means of moving forwards.
> > 
> > Thanks,
> > 
> > James
> > 
> > >  For other extensions which make the structure totally
> > > incompatible
> > > you can use the critical flag. Anyway even the original struct is
> > > OK,
> > > it is exactly like any other key structs we have.
>