Moving attestation generation and verification code to `attest` repo.

[ameba23]

@alexhulbert has started https://github.com/flashbots/attest which can compute measurements from an OS image together with CVM configuration.

The idea is that CVM configuration data would be sent as part of the attestation evidence payload, and a verifier would use it to compute the expected measurements for that particular instance. Eg: for GCP we would probably include the machine type and region. This would save us needing to have pre-computed measurement values for every combination of accepted OS image version and CVM configuration.

Since this involves both generation and verification, the proposal is to move the contents of the attestation crate over to that repo.

If doing that, it would probably also make sense to move the pccs crate and not-yet-merged mock-tdx crate there as well, as i think they belong together with attestation rather than attested-tls.

The alternative would be to do it the other way around and move everything into this repo.

Tagging @0x416e746f6e as you were not around when we were talking about this last week.

[0x416e746f6e]

perhaps we should merge attest into this repo, and then rename this repo into just attestation.

(there is another PR for attestation provider server/client to be placed here => i.e. we begin to have very related tools/libs crawling in different directions)

[ameba23]

perhaps we should merge attest into this repo, and then rename this repo into just attestation.

I'd be happy with that since it would keep everything together for audit.

But regardless of which way around we do it, i'd like to get clear on what is our policy on signing-off PRs. Eg: require one review from any of us?

cc: @alexhulbert

[0x416e746f6e]

require one review from any of us?

that, or use codeowners to indicate reviewers on per-crate basis

[alexhulbert]

We should definitely keep the crates in attest separate from attested-tls. Attest and attested-tls are large enough as is, and we will likely have to get them audited separately anyway, since attest is 100% TDX systems code and attested-tls is 100% networking. Auditors for TLS stuff are in higher supply, an order of magnitude cheaper, and they're a totally separate niche. The simple three-function prove/verify/measure interface makes the problem of auditing attested-tls entirely self-contained from auditing attest.

I'd argue that for auditability, having the entire measurement/prover/verifier stack be a small, self-contained 3000 line GitHub repo is pretty much ideal.

Keeping them separate also makes it easier for the numerous companies that have rolled their own TDX prover/verifier/measure stacks to switch to ours without having to concern themselves with attested-tls code, which they may or may not want to use.

[ameba23]

I don't have strong opinions about which repo the attestation code lives in, but i do feel strongly that we continue to maintain it collaboratively.

We've made a bunch of changes to the attestation code to fit the needs of the attested-tls protocol and i expect we will continue to do that, which would mean paired PRs between the two repos which need to be reviewed together.

We still have open PRs in this repo which effect the code which has been copied to attest. The longer that code is duplicated and being modified in two places, the harder it is going to be to resolve.