[svsm-devel] vTPM service attestation format update

[James Bottomley]

On Thu, 2025-02-20 at 17:17 -0800, Dionna Amalie Glaze wrote:
> I'd like to propose a new version to the vTPM protocol that is
> clearer
> about its EK information.
> It's possible to create multiple primary endorsement keys with
> different algorithms.
> 
> For manifest version 1, we have a list of created primary keys in
> TPM_ALG enum order, not creation order.
> 
> 0x000 uint32 Number of primary endorsement keys
> 0x004 Variable Number-many TPMT_PUBLIC structures
> 
> I don't want to try to load a lot into this change request. For
> reducing pain with make/activatecredential, there's more to discuss.

I'm not sure I exactly understand the proposal, but I think it's that
the type of endorsement key should be part of the input data to the
vTPM protocol attestation?  In which case I agree.

However, the last sentence about make/activate credential makes me
think you're being too traditional about this.  That protocol is really
only required because physical TPMs are only shipped with encryption EK
certificates to force the privacy preserving algorithms.  Since there's
no privacy concerns about the vTPM in a confidential system, we can
just produce a signing EK, which can itself certify TPM objects without
the need for doing the AK creation dance.

That argues that there should be two input arguments: algorithm and key
type.

Reegards,

James