Re: SVSM Attestation and vTPM specification additions - v0.60

[Tom Lendacky <thomas.lendacky@amd.com>]

On 1/10/23 15:47, James Bottomley wrote:
> On Tue, 2023-01-10 at 15:32 -0600, Tom Lendacky wrote:
> [...]
>> My thoughts were to again use GUIDs to identify the key and key-type
>> present, i.e. EK RSA-2048 or EK EC (NIST-P256), etc:
>>
>>          16-byte data GUID (e.g. EK EC (NIST-P256))
>>          4-byte data length
>>          data
>>
>>          16-byte data GUID (e.g. SRK EC (NIST-P256))
>>          4-byte data length
>>          data
> 
> I really wouldn't use GUIDS because the TPM structures should all be
> self describing.  The structure we're thinking of packing into the
> attestation report to be hashed with the nonce is the TPMT_PUBLIC of
> the EK.  The algorithm, attributes, policy and name hash which are in
> the public area should define the exact template that was used to
> construct the public key.  Note that there are about 2^70 possible
> combinations, which is why I don't think you want a GUID for each one

Ok, so this is different from what was originally talked about being just 
the EK EC key andr the SRK EC key.

A GUID still works, though, to describe that the TPMT_PUBLIC supplied is 
for the EK - unless you want to go with the known handles, e.g. 0x81010001 
for the EK RSA handle or 0x81010002 for the EK EC handle, etc. You still 
need to identify what key is represented by the TPMT_PUBLIC structure, 
right, or am I missing something about the TPMT_PUBLIC structure?

Thanks,
Tom

> ...
> 
> James
> 
>