Format of environment

[jraman567]

I want to explain how to specify the environment in a CMW collection. The environment record in the collection would appear as follows:

environment-record = (
        type: tstr
        value: base64url-string
)

"env": [
        "application/signed-rim+cbor",
        << base64 encoded environment map >>
]

We can utilize the environment map as outlined in the CoRIM specification. In this case, we could create a CoRIM that includes only environment endorsement, excluding Trust Anchors or Reference Values, provided the specification allows this.

Alternatively, we could establish a new type specifically for the environment.

Here is how the CoRIM specification defines the environment:

class-map = non-empty<{
        ? &(class-id: 0) => $class-id-type-choice
        ? &(vendor: 1) => tstr
        ? &(model: 2) => tstr
        ? &(layer: 3) => uint
        ? &(index: 4) => uint
}>

environment-map = non-empty<{
        ? &(class: 0) => class-map
        ? &(instance: 1) => $instance-id-type-choice
        ? &(group: 2) => $group-id-type-choice
}>

[deeglaze]

To allow for CBOR representation, you'd not need base64 encoding.

environment-record = (
  type: tstr
  value: JC<base64url-string, bstr .cbor environment-map>
}

If you're using ratsd as lead attester to define the environment it's measuring, rather than deferring to a combination of policy and subattesters' own environments, I can see this as a useful inclusion.

I would want to ensure that the trust of the lead attester depends on the trust of the sub-attesters, so you can define domains by their CMW tree address by '.'-separated labels, and express parent -> child dependencies that way with domain triples as inherent to the tree structure of the CMW.

How are you using environment beyond identifying the lead attester though? I would be wary of specializing too much to a platform when the reference value of a piece of software / firmware should be transferrable across platforms.

[jraman567]

We should also vet the content media type for each message in a CMW collection to ensure that they include an environment/tag in a standardized (preferably CoRIM) format.

Alternatively, we could enhance the CMW to include this as a separate field.

[yogeshbdeshpande]

Hi Jag,

I am not sure what you are trying to do. if you are putting the CoRIM with a Endorsed Triple, which has an [Env, Endorsement]?

is it your use case ?

[yogeshbdeshpande]

If the answer above is yes then please add the Entire CoRIM as a CBOR in the cbor-CMW
type: "application/signed-rim+cbor",
value: bytes
? ind: 1 (basically cm-type=endorsements)

[jraman567]

Hi Yogesh, we are discussing including the environment information in the evidence. Since the evidence won't be in a CoRIM format, I wonder how to specify their environment.

1. In a CMW collection, should the environment information be for each CMW or for the whole collection?
2. If we choose to specify it per CMW, where should we do it? Is it worth adding a new field to CMW to determine the environment?

[thomas-fossati]

@jraman567 CMW is a conceptual message (CM) wrapper. In RATS, CMs are one of evidence, refvals, endorsements, attestation results, and policies. Other CMs may be defined in the future, but this is the complete list at the time of writing. So, a standalone CoRIM environment is not a CM. If you want to convey it in a CMW, it needs to be serialised as part of a CM (e.g., CoRIM tag, an EAT token, etc.)

[deeglaze]

I think we all have different conceptions of what an environment is, and that's a specification problem.

An environment is named by an attester that collects measurements of that environment. In DICE, each handoff layer is its own environment, since it exists to measure the next layer. It's important to think about the DICE origins of CoRIM's environment concept.

Layer 0 of DICE is still mutable code, so what measures that is derivation from the the DeviceID, which is derived from a secret burned into the chip.
We don't have a DICE boot stack through UEFI to Linux, as nice as that would be. The Caliptra project has a reference implementation of a DICE Protected Environment (DPE) that we could conceivably use throughout, but that would take a change to the UEFI spec for how to track measurements, and a spec from the TCG for a DICE-based platform firmware profile. Similarly we'd need enlightenment to shim and grub to handle the new DPE-based measurement and handoff protocol. In Linux, IME would no longer be possible, since each measurement is not changing execution context to a completely different handoff layer.

So where does this leave us in ratsd? We lose the layering idea of DICE when we use ratsd to bootstrap TLS for Kubernetes because we don't hand off to the runtime's execution of a pod—we isolate it. In that unit of isolation, we want to attest to just the workload at the security boundary, and a container is not a security boundary. Depending on the runtime, we might be directly measuring to the RTM when there's no isolation, and we might be measuring to a separate measurement chain held by ratsd and made available to the pod through a local network connection. We kind of have a layer under ratsd, that is the environment of an isolated workload. If the pod uses its own ratsd process to collect measurements for connections from the workload, they'll be acquired through the inner ratsd requesting a quote from the outer ratsd.

The outer ratsd has its own environment for node-level attestation. The topology of its composite attestation is part of its evidence. As part of bootstrapping the inner ratsd, it could provision a certificate for an ephemeral key as justified by its composite attestation evidence. The certificate can contain the evidence or the attestation results as part of the certificate's extensions, depending on how much an operator wants to be made visible in the certificate chain to the workload.

What we don't get from the ratsd environment is what a node deployment that includes ratsd should expect the measurements to be. Indeed what's allowable by Verifier policy is up to policy. What could be part of policy too is that evidence includes a posited Bill of Material for the node deployment. That CoBOM identity, if allowed by policy, could then be used to construct an appraisal context to then verify evidence that indeed that CoBOM applies to the ratsd-measured evidence.

Environments are not a whole platform. You can have a whole DAG of attesters' environments collecting evidence about a node/system. That dependency relationship can be captured in the form of domain membership triples.

What I haven't determined yet is if we want to use domain dependence as a guiding force for TPM event ordering. Stay tuned for a CoRIM profile for PCClient event logs.