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

[Nikos Mavrogianopoulos]

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. 

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.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20161226/17a2127e/attachment.html>