Re: [PATCH RFC 17/20] attestation: Add CTLV operation handling

[Yeoreum Yun]

[..snip..]

> +static int attestation_evidence_request_decode(struct attestation *att, struct ctlv_op_ctx *ctx,
> +					       const struct ctlv_cursor *request,
> +					       struct attestation_evidence_request *decoded,
> +					       struct attestation_evidence_object_request **objects)
> +{
> +	const struct attestation_evidence_caps *caps = att->provider->evidence_caps;
> +	u32 challenge_length;
> +
> +	decoded->challenge =
> +		ctlv_attestation_evidence_get_evidence_challenge_get(request, &challenge_length);
> +	decoded->challenge_length = challenge_length;
> +	if (challenge_length < caps->min_challenge_length ||
> +	    challenge_length > caps->max_challenge_length)

Hmm, I'm not sure whether this check is required for
ATTESTATION_EVIDENCE_BLOB_EVENT_LOG blob type.

for example, if the provider provides two evidence:
  - ATTESTATION_EVIDENCE_BLOB_PRIMARY (might attestation token)
  - ATTESTATION_EVIDENCE_BLOB_EVENT_LOG

might challenge is reuiqred for generating the token
and this would be marked at min/max_challenge_size in evidence_cap.

However, in case of eventlog, it wouldn't require challenge.
for example, TPM event log or CCEL event log.

Do we need some field on attestation_evidence_supported_object whether
it requires challenge or not and applies this sanity check per the object?

Otherwise, to get eventlog, it would need to send *dummy* challenge
always.

[...]

-- 
Sincerely,
Yeoreum Yun