Adopt EAR in Attestation Service

[fitzthum]

Following @thomas-fossati's excellent presentation about EAR in the community meeting, I think we should move towards replacing/reformating our attestation token to use EAR. There are a few pieces that we'll need to think about.

Currently the AS returns a JWT with these claims inside of it. Code for token issueing is here.

let token_claims = json!({
    "tee": to_variant_name(&tee)?,
     "evaluation-reports": policies,
      "tcb-status": flattened_claims,
      "reference-data": reference_data_map,
      "customized_claims": {
          "init_data": init_data_claims,
           "runtime_data": runtime_data_claims,
      },
});

Part of the question is how we can map these claims onto EAR. I don't have a thorough knowledge of the EAR format yet, so I don't have a lot to say about this. I do wonder if we should drop the reference-data field. I am also not sure if there is something like the TEE field. I guess EAR is supposed to be platform independent, but it is reasonable for a KBS to have policies based on this info (i.e. don't release secrets to a guest with the sample attester).

There are two deeper questions that I am concerned about. First, how do we produce the EAR trustworthiness claims. Currently evidence validation in the AS is based on OPA. Each verifier plugin extracts a claims map (also stored in the tcb-status field of attestation token) which is fed into the OPA engine. The output of the policy evaluation is stored in the policies field. Note that we support evaluation of multiple different policies. I'm not sure if we should continue with that or how to work it into the EAR format.

The bigger issue is that we currently have very loose requirements for what the AS validation produces. The OPA policies can essentially return anything. It is up to the client to synchronize their AS policies with their resource policies in the KBS. This is quite different from the EAR approach where the format of the attestation results are more strongly structured. I'm not sure how we should account for this. Maybe we can provide OPA policies that transform claims maps into trustworthiness claims. Maybe we should get rid of the OPA engine in the AS entirely. This is related to some of the discussion here.

Another issue is how we handle init_data. The init_data expresses the configuration of many components in the guests. This reflects crucial information about the guest TCB and potentially about the workload as well. Inidata is not hardware specific. Currently the AS ensures a binding between the hardware evidence and the initdata, then it is up to the policy to validate the initdata. Even without EAR I think we're a little uncertain whether the inidata should be validated in the AS or the KBS. Since it is closely related to the resources that are allowed, this should probably be handled by the KBS. I guess this means that it would not be part of the EAR? This flow is still unclear to me.

Overall I think the EAR is a good approach, so let's see if we can get the ball rolling here.

cc: @Xynnn007 @mkulke @mythi @sameo