RE: SVSM vTPM specification

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

On Fri, 2022-10-21 at 00:02 +0000, Jon Lange wrote:
> Surely the primary value of a document hash is to prove its
> authenticity, not to determine whether two documents reflect
> identical information.  I understand your concern that two
> "canonical" representations of the same data may result in different
> JSON encodings and therefore produce different hashes, but as long as
> each document can be authenticated by its hash, does it really matter
> if the hashes of the two documents are different?

If you only have an AMD-SNP attestation report and access to the vTPM,
you have to query the TPM properties then construct and hash the
document yourself to verify the report.  I sometimes think half the
history of security protocol implementation consists of one engineer
struggling to reproduce the hash created and signed by another, which
is why I have a preference for it being exactly specified and simple.

> There is a ton of discussion here about vTPM because it's an
> important problem, and it is valuable to recognize that a vTPM
> implementation will likely require some sort of SVSM-issued document
> to describe that vTPM.  There's no reason to back away from defining
> the structure of such an SVSM-issued document.  But we should also
> expect that in the next 2-3 years, we're going to invent other
> valuable functionality that an SVSM can implement that will also
> require the SVSM to issue some sort of authenticated statement.  If
> we marry the SVSM report information to a vTPM, then it's going to be
> really hard to add that new functionality, and if we don't anticipate
> the need for extensibility, then we're going to wind up in a future
> where an SVSM will issue different kinds of authenticated information
> (vTPM on one hand and new feature on the other) and the relying party
> won't be able to know which is which.  I don't see how we can avoid
> the problem of defining an extensible document schema now that we can
> extend in the future as the role of the SVSM expands.  JSON is an
> extremely attractive syntax for such a schema - certainly much more
> so than XML, and also likely to fare much better than any binary
> standard.

Allowing the relying party to know what type of authentication was why
I proposed a type prefix to the guest data in the report.  The reason I
like the type in the guest data and not the hash is so the bare report
is self identifying even if it costs us a byte or two of the nonce.

There are 2^32-1 possible SVSM protocols, so nothing in the above
precludes adding a json based hash call if a need arises (or indeed
many other binary/json/xml ones if that's what people prefer).

James