DCAP shouldn't translate all valid statuses to SgxStatus::OK

[brenzi]

Upon verifying the dcap quote itself, the status can't be derived, therefore, we return OK here:

https://github.com/integritee-network/pallets/blob/75c7bdcd54736ea2fceb33ba215e1a1718420ed3/teerex/sgx-verify/src/lib.rs#L617

later, when we verify TCB info, the Status should actually be overwritten with the real one: https://github.com/integritee-network/pallets/blob/75c7bdcd54736ea2fceb33ba215e1a1718420ed3/primitives/teerex/src/lib.rs#L300

This problem is tricky because we don't know if the onchain TCB info which defines SgxStatus is the most recent one available. we can only check if an update is due with the nextUpdate timestamp. However, if an enclave is more on more recent state, it can always trigger an update of TCBinfo itself

[brenzi]

the above statement is not entirely correct.

At the time of registering TCB collateral, all TCB version statuses which are outdated are purged:

https://github.com/integritee-network/pallets/blob/75c7bdcd54736ea2fceb33ba215e1a1718420ed3/teerex/sgx-verify/src/collateral.rs#L206-L207

https://github.com/integritee-network/pallets/blob/75c7bdcd54736ea2fceb33ba215e1a1718420ed3/teerex/sgx-verify/src/collateral.rs#L101

So, the issue is not severe. Still, it's not how we'd like it to be if we store SgxStatus with the enclave struct as we do now

Solving this will be a state breaking change because we need to store more information onchain in the tcb collateral registry

[brenzi]

we currently face the issue that outdated systems are simply rejected. that's not good for onboarding. warnings are fine, but rejection is bad. so I guess this issue should have priority