RE: SVSM vTPM specification

[James Bottomley <jejb@linux.ibm.com>]

On Thu, 2022-10-20 at 19:58 +0000, David Altobelli wrote:
> From: Steve Rutherford <srutherford@google.com>
> 
> > I'm a little leary of JSON in the SVSM. My fears of JSON parsers in
> > high trust tools might be unfounded though. Broadly speaking, the
> > idea of having something that contains what was >hashed would be
> > nice for future proofing. Having flexibility in which keys/data are
> > hashed into the report seems wise.
> I'm partial to JSON, but any format would do.  If parsing is
> problematic, outputting JSON data doesn't actually require parsing,
> it's just formatting some strings.

I too would prefer a format whose hash doesn't depend on how you
canonicalize it.

> > Separately, it's not clear to me why we need to attest to the SRK.
> > My understanding was that it was primarily used locally, and that
> > attestation was the job of the endorsement hierarchy. >Once you
> > have an EK, you can go through the necessary motions to certify the
> > SRK. That said, I can imagine wanting the hash of a standardized
> > AKpub to simplify those flows.
> Agree on not needing SRK, and AKpub (or AIKpub) being
> interesting.  Maybe there are some core claims that every
> implementation would want to offer, along with whatever optional
> claims improve their scenario?

Getting a TPM to certify a SRK given EKpub isn't simple.  You have to
create an AK in the TPM; do a make credential/activate credential round
trip on the AK to verify it against EKpub and then use the AK to
certify the SRK.  We could short circuit this if the EK were a signing
key ... then it would be able directly to certify the SRK.

James