[svsm-devel] vTPM service attestation format update

[Ndu, Geoffrey]

I'm not sure how the TPM_ALG approach would work for default EK templates
that use the same algorithm. 
For example, Template L-1: RSA 2048 (Storage) and Template H-1: RSA 2048
(Storage).

Geoffrey

-----Original Message-----
From: Svsm-devel <svsm-devel-bounces at coconut-svsm.dev> On Behalf Of
svsm-devel-request at coconut-svsm.dev
Sent: 21 February 2025 11:00
Date: Thu, 20 Feb 2025 17:17:48 -0800
From: Dionna Amalie Glaze <dionnaglaze at google.com>
To: svsm-devel at coconut-svsm.dev
Cc: "Lendacky, Thomas" <Thomas.Lendacky at amd.com>,  James Bottomley
	<James.Bottomley at hansenpartnership.com>
Subject: [svsm-devel] vTPM service attestation format update
Message-ID:
	<CAAH4kHZg_f--LJhw0zu9bYe87ozQX1jgxhQwJS+-=g0-u0DZTQ at mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"

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.
--
-Dionna Glaze, PhD, CISSP, CCSP (she/her)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5480 bytes
Desc: not available
URL: <http://mail.8bytes.org/pipermail/svsm-devel/attachments/20250221/d5fd2e3c/attachment.bin>