Move logic for providing evidence for remote attestation claims to the untrusted part of the server

[tiziano88]

Currently the evidence (signatures over the binary hash, endorsement files, inclusion proofs, etc.) are sent by the server each time withi the additional data field of the remote attestation handshake.

In principle though, there is nothing secret about those, and, additionally, if the client connects to the same server (or to any other server with the same measurement) and already has the appropriate signatures cached locally, there is no need for the server to send them each time.

Additionally, passing some static data all the way through to the trusted runtime just to be served as part of the handshake seems unnecessary.

I think we may be able to implement this so that the client can just request this information from the untrusted portion of the server (e.g. with a message of a different type over the established stream), so that it may even be skipped in most cases if the client does not need it (we probably would also change the client to cache such information locally (not just the evidence, but also the conclusion of which hashes are trusted), so that subsequent connections don't need to re-validate them).

@rbehjati @ipetr0v @conradgrobler WDYT?

[tiziano88]

In case of unary requests, I think this gets even simpler to implement (just a different API endpoint exposed on the same server).

[rbehjati]

Sounds like a good idea. I am not sure, but IIRC, we decided to include the additional info in the remote attestation handshake to make the remote attestation state machine simpler. But it is not necessary to exchange this information during the handshake.

[conradgrobler]

I also think it is a good idea and caching that part of the verification makes sense.