Generalize Challenge in QueryRequest and Attestation-payload in QueryResponse

[mcd500]

This is summary of these issue [Too big challenge size] https://github.com/ietf-teep/teep-protocol/issues/202 and [full EAT CDDL example in TEEP Protocol] https://github.com/ietf-teep/teep-protocol/issues/213.

The contents of challenge in QueryRequest and attestation-payload in QueryResponse are used for attestation. How to handle them would be different on CPUs, TEE-OSs and any other implementations. And also would be nice if these fields could support both remote attestation and local attestation.

I would like to make the format of challenge and attestation-payload generic to be able to contain any values in them, so it will be able to support all variants mentioned above.

I will propose the size of the challenge to keep the current definition discussed at the https://github.com/ietf-teep/teep-protocol/issues/202.

challenge => bstr .size (8..512)

And using the proposed attestation-payload format in https://github.com/ietf-teep/teep-protocol/issues/213.

attestation-payload = [
  type: $TEEP-payload-type,
  attestation-body: teep-evidence / teep-attestation-result / tstr / bstr
]

The TEEP Protocol messages will be responsible for carrying values for remote attestation and local attestation. The Verifier which is in the back of the TAM (background check model) is going to perform the remote attestation with the TAM. The same field of challenge and the attention-payload will be used for the TEEP device and the TAM to perform local attestation.

These are the example for the sgx:

sgx: remote attestation: QueryRequest: challenge 　sgx_quote_nonce_t sgx: remote attestation: QueryResponse attestation-payload 　sgx_quote_t (https://github.com/intel/linux-sgx/blob/master/common/inc/sgx_quote.h#L75) sgx: local attestation: QueryRequest: challenge 　sgx_target_info_t sgx: local attestation: QueryResponse attestation-payload 　sgx_report_t (https://github.com/intel/linux-sgx/blob/master/common/inc/sgx_report.h#L113)

Any comment is welcome.

[dthaler]

@mcd500 This is what the attestation-payload-format is for, it should already be generic. Issue #217 and PR #216 should, in my opinion, be sufficient to address this since it clarifies that the profile parameter can appear, so you have both the media type and any parameters, to explain what is in the attestation-payload.

If you agree, I think this could be closed as a duplicate of 217.

[dthaler]

Fixed in draft -09

[mcd500]

Moved to https://github.com/ietf-teep/teep-protocol/issues/224. Ready to close.