Capabilities of the Attestation Mechanism about architecture HOT 3 CLOSED

For SGX, and for other Intel TEEs, the Attestation Key is generally restricted, so you cannot sign "anything".
Typically the way this works (for Intel) is you get a signed attestation that includes a 256-bit or 512-bit value. This value could be a random nonce sent from the remote verifier, or it can be a hash of another structure "attached" to the attestation. In the case of a hashed structure, the verifier then must interpret the structure. The implication is that the attestation gives you data on the claimant, and the claimant provides the additional data. If the verifier believes it can trust the claimant based on the attestation, then it should be able to make some policy decision on the additional claims.

For TEEP running in SGX, the provided attestation would be an additional structure, which would be hashed, and then this hash would be signed in an attestation which would provide details of the SGX enclave code that requested the attestation (things like enclave-signer, hash-of-enclave-code, enclave-version-number, CPU-microcode-version, etc.) The verifier (TAM in this case) would need to validate the SGX Attestation, and then interpret the attached structure.

Hope this is clear enough.

from architecture.

See new Pull Request to address this issue

from architecture.

Filed a separate issue to track impact on the OTrP spec.

from architecture.