Since we reference this error enum from mod.rs, it should not
be rego-specific. The error variants are not specific to OPA,
so lift them into mod.rs.

Now, someone writing an alternative policy engine
can use the same errors.

Signed-off-by: Tobin Feldman-Fitzthum <[email protected]>

This commit allows the AS to issue EAR tokens with the
help of the rust-ear crate.

EAR tokens require particular claims. This creates a binding
between the AS policy and the EAR token.
Specifically, the policy engine must return an EAR appraisal.
The policy engine is still generic. Multiple policy engines
could be implemented as long as they create an appraisal.

Since policy evaluation is now closely tied to the type
of token we are going to generate, make the policy engine
more generic and move the logic around calling the policy engine
out of lib.rs and into the token broker.

There are a few other changes, including that the policy engine
no longer takes multiple policies. For now, we only evaluate
the first policy in the policy list, but future commits will
change this convention so that we only ever think about one
policy for the attestation service (until we introduce support
for validating multiple devices at once).

EAR Tokens also do not use flattened claims.

The TCB claims are currently flattened so that we can use the
key names as the input to the RVPS. This commit breaks this
functionality, but a future commit will change the way
the RVPS works to accomodate. There isn't a direct pairing
between claim names and reference values, so there is no
reason to keep flattening all the claims, especially
because the flattening code has some corner cases
that it does not support.

This commit also adds the init_data_claims and
runtime_data_claims to the tcb claims as long as
the corresponding claims about the hashes are already there.
This will allow the init_data to travel with the token,
which will be convenient except if the init_data is too big.

Signed-off-by: Tobin Feldman-Fitzthum <[email protected]>
Signed-off-by: Xynnn007 <[email protected]>

For EAR tokens we require the public key to be set.
There is no option to deserialize a token without
validating the signature.

Signed-off-by: Tobin Feldman-Fitzthum <[email protected]>

A keypair is required to sign and validate the attestation token.
In the past this was optional, but now it is not.

Update the docker-compose manifest and configs to pass in this
new keypair and update the docs to tell people how to generate it.

This does complicate the user experience, but things are not secure
without it. That said, we may be able to implement this automatically
in a future PR.

Signed-off-by: Tobin Feldman-Fitzthum <[email protected]>

Now we need to provision a keypair for signing and
validatig the attestation tokens.

Add this keypair to the docker e2e test

Signed-off-by: Tobin Feldman-Fitzthum <[email protected]>

The sample attester is enabled by default.
Remove setting the environment variable that used to
enable it.

Signed-off-by: Tobin Feldman-Fitzthum <[email protected]>

We now require a keypair for signing/validating the attestation
token. Add this keypair to our k8s deployment tooling.

Signed-off-by: Tobin Feldman-Fitzthum <[email protected]>

We now require a keypair to sign/validate the attestation
token. Add this keypair to the e2e test.

Interestingly, we were using a keypair for validating
the old CoCo token in this test, but only for the
passport mode. Even in background check mode, this keypair
is required or the token won't be validated at all.

Signed-off-by: Tobin Feldman-Fitzthum <[email protected]>

Previously we expected the caller of the RVPS to provide
a name for the reference value that they wanted.
In the AS we were flattening the TCB claims to get this name.
Ultimately, the names of the TCB claims do not map directly onto
the names of the required reference values.

This changes the interface to have the RVPS determine which
reference values to send. At the moment, it simply sends all of them.

This allows the reference values that are used to mostly be set within
the policy itself, which is probably a good idea.

In the future, the RVPS should be improved to include a context
abtraction that allows groups of reference values to be provided to the
AS.

Signed-off-by: Tobin Feldman-Fitzthum <[email protected]>

THe skeleton for a policy that can be used to validate the TCB
claims of all platforms in the context of confidential
containers.

Only sample and snp are supported currently, but this should give
a good idea of how to extend the policy to other platforms.

There are a few tweaks we can make later, such as supporting
`>` or `<` comparisons.

Signed-off-by: Tobin Feldman-Fitzthum <[email protected]>

Update the attestestion service policy docs to describe the
requirements for policies that will generate EAR tokens.

Also update various example and default policies.

Signed-off-by: Tobin Feldman-Fitzthum <[email protected]>

EAR tokens do not support an expiration claim by default, but
fortunately we can use the Extension framework to add an `exp` field
that will match what we would expect in a JWT.

Add this extension and check it when we validate the token.

Signed-off-by: Tobin Feldman-Fitzthum <[email protected]>

Now that the as policy engine is more generic, re-enable and update the
test.

This test is slightly tied to EAR.

Signed-off-by: Tobin Feldman-Fitzthum <[email protected]>

The rust-ear crate now supports null json value so we can remove the
workaround we had to make sure null value didn't cause an exception.

Signed-off-by: Tobin Feldman-Fitzthum <[email protected]>