More feedback on TPM appdx from MSJ

[ounsworth]

See mail-list thread:
https://mailarchive.ietf.org/arch/msg/spasm/mN2o2mP8mAKfQub6olWThF8ftMk/

---

So I still have issues with this section (and yes, I'm now working from
the -10 draft):

1. There is no functional mapping from a SubjectPublicKeyInfo to a
   TPMT_PUBLIC [f(spki)->tpmt_public], which means there is no guaranteed
   way to calculate the TPM2B_NAME "name" field in the attestation's
   TPMS_CERTIFY_INFO from the SPKI in the CSR. You can however calculate
   the TPM2B_NAME from a TPMT_PUBLIC object, and you can match a
   TPMT_PUBLIC to an SPKI allowing you to verify that the attestation is
   about the public key in the CSR. This makes the TPMT_PUBLIC mandatory
   to complete the attestation of a public key, not optional. A
   discussion of how to map across this set of relationships rather than
   going into details of the various structures appears necessary or at
   least pointers to the sections in the TPM documents.

2. (Section A.2.5.5) There's a TPM2B_DATA qualifyingData argument to the
   TPM2_Certify command that can be used to provide nonce data. To verify
   the attestation, you need to know what nonce the TPM used to form it.
   There needs to be a field in Tcg-csr-tpm-certify to provide for the
   carriage of this value. If it's omitted, a standard value is provided
   at the time of the creation of the attestation. "qualifyingData" is an
   input used in all 6 of the TPM certify commands and should not be
   omitted from the example. It may be optional in the structure, but must
   not be omitted if the attestation formation used qualifyingData.

3. A.2.5.2 - "This document will specifically define..." seems to imply
   that you can safely ignore the TPMV2 documents definition of TPMT_PUBLIC
   in favor of this documents definition- that seems strange.

4. Same section. If you're going to expand the TPMA_OBJECT structure,
   it might be useful to describe what a relying party might want to check
   here. E.g. generated on the TPM, not extractable, either a signing, key
   agreement or encrypting and not a restricted key.

5. A.2.5.3 - You've chosen to carry the signature in the TPM way - it
   could also be carried in a PKIX way. Either is valid, the second might
   be easier for a relying party to handle.

6. Most of the A.2.5 section would be better if removed and replaced
   with document references to the actual TPMV2 documents.

7. A.2.6 - I'm assuming that the CA certificate in the CSR
   EvidenceBundle.certs is the CA certificate that signed the AK. I'm
   unclear why it's here unless its an intermediate CA subordinate to a
   well known root of trust. (Looking at the asn1 dump, that doesn't seem
   to be the case).

8. Some discussion of what information the verifier needs to give you an
   answer might be useful. (e.g afaict, a Verifier needs the CSR's key to
   be certified, the TPMT_PUBLIC content octets, the signature content
   octets and the attestation content octets. Or it needs to be able to
   parse ASN1 from the entire CSR.

Item's 1 and 2 need to be fixed. (3) may need to be fixed, or at least
reworded. Items 4-8 would add useful content, but are mostly a don't
care from my point of view.

Later, Mike