Clarify use creating and verifying TPM attestation statements. #2193
Conversation
…referece to EK-Profile to current version.
| whose `name` field contains a valid Name for |pubArea|, as computed using the procedure specified in [[!TPMv2-Part1]] section 16 using the nameAlg in the |pubArea|. | ||
|
|
||
| Note: The hash algorithm is also included within the attested `name` | ||
| field of the TPMS_CERTIFY_INFO structure and will also match nameAlg in |pubArea| when returned by the TPM. |
There was a problem hiding this comment.
Suggest changing "will also match" to "MUST also match", thereby making this normative and an error if the RP detects that the hash algorithm is different in these two locations.
There was a problem hiding this comment.
By making this a note, this is an informative statement so not sure if we can make this normative. This clarification, in fact, is what I believe is the source of the original concern that there was a possibility these would be different, when, in fact, the TPM never changes the algorithm. Making this check a MUST alludes that the TPM might return these different. That said, as the algId in the Name is not protected it is possible for software (local or in transit) to change it but the worse case would be a DOS attack (unless someone finds a pre-image attack). With that said, I'm open to the suggestion if you still believe that's needed.
There was a problem hiding this comment.
The problem I have with lowercase "will also match" is that it's suggestive, without providing guidance to the RP as to what to do if its observed that the values are not the same in both locations. I'm not going to die on this hill though.
| section 31.2, i.e., `qualifiedSigner`, `clockInfo` and `firmwareVersion` are ignored. | ||
| These fields MAY be used as an input to risk engines. | ||
| Depending on the properties of the |aikCert| key used, these fields may be obfuscated. | ||
| If valid, these MAY be used as an input to risk engines. |
There was a problem hiding this comment.
How does the RP determine if the fields are valid or not?
There was a problem hiding this comment.
The content of these fields is determined by which TPM hierarchy the AK is in. (tl;dr: If the AK is in the Endorsement hierarchy the fields are valid, if the AK is in the Storage hierarchy, the fields are random - this is for privacy reasons). To provide information about where the AK is may be a privacy concern so this is not provided in the protocol. The properties of the AK (including whether to even trust it) are out of scope for this protocol and it would be up to the RP to know that out of band.
| @@ -6582,6 +6591,11 @@ TPM [=attestation certificate=] MUST have the following fields/extensions: | |||
|
|
|||
| - The Subject Alternative Name extension MUST be set as defined in [[!TPMv2-EK-Profile]] section 3.2.9. | |||
|
|
|||
| Note: Previous versions of [[!TPMv2-EK-Profile]] allowed the inclusion of an optional attribute, | |||
| called HardwareModuleName, that contains the TPM serial number in the EK certificate. | |||
| HardwareModuleName SHOULD NOT be placed in in the [=attestation certificate=] | |||
There was a problem hiding this comment.
I suggest changing "SHOULD NOT" to "MUST NOT" for privacy preserving reasons.
There was a problem hiding this comment.
Agree MUST NOT would be my preference. However, my concern with MUST NOT is if there are any existing implementation that followed the original wording, MUST NOT would make those existing implementations (if >0) non-compliant which would not be their fault. I'm OK with the guidance of the WG on this.
|
@mwiseman-byid, you should have received an email from IPR Bot asking for your commitment to this PR, as you're not part of this specific W3C Group. I am available if you need more information. |
|
@mwiseman-byid, the bot is happy. So, from IPR perspective, we're done. |
|
thank you
|
Closes #1925
Addressed potential implementation errors in TPM Attestation
Implementation commitment:
Addressed potential implementation errors in TPM Attestation
Addressed potential privacy issues
Documentation and checks
Preview | Diff