allowing domains to be domain members

[nedmsmith]

Current domain triples don't allow device composition using domain namespaces and current tag semantics only imply device composition. CoBOM describes tag activation, meaning the set of tags containing information that is related to a device can be specified, but it doesn't define hierarchical relationships between tags. Some tags, such as ta-stores, do not imply device composition. Comid and coswid tags have linked-tags relationships that help manage tag lifecycles, but tag-ids are not long lived. Hence, they are not ideal for representing device composition.

Domain namespaces have long lived identifiers, but the current domain-membership-triple-record only allows multiple environment-map entities to be members of a domain namespace. The domain-dependency-triple-record has semantics that traces trust dependencies which shouldn't be overloaded with domain membership semantics.

This issue proposes extending domain-membership-triple-record to include $domain-type-choice objects. This will allow it to be used to construct a device composition hierarchy using long lived identifiers.

A comid tag could be defined to implicitly contain a domain namespace that is unnamed. A domain membership triple that uses the same domain name for the subject and the object could be used to assign a long lived domain name to a comid tag.

E.g.,: Tag-1 contains:

/ domain-membership-triples / 5 : [
       [  
         subj: "X",
         obj: [ "X" ]
      ]
]

Multiple domains could exist within a tag if a second domain name appears within the same triple object as the triple subject. E.g.,

/ domain-membership-triples / 5 : [
       [  
         subj: "X",
         obj: [ "X",  "Y" ]
      ]
]

Multiple tags can be related by composition using membership triple where both have self-asserted namespace names and a membership triple links them together. e.g., Tag-2 contains:

/ domain-membership-triples / 5 : [
       [  
         subj: "Z",
         obj: [ "Z" ]
      ]
]

And tag-1 contains:

/ domain-membership-triples / 5 : [
       [  
         subj: "X",
         obj: [  "X",  "Z" ]
      ]
]

The cddl would be something like:

domain-membership-triple-record = [
  $domain-type-choice
  [ + $domain-member-type-choice  ]
]
$domain-member-type-choice /= environment-map
$domain-member-type-choice /= $domain-type-choice

[thomas-fossati]

Hi @nedmsmith, see this musing on composition which has a few overlaps.

[nedmsmith]

Hi @nedmsmith, see this musing on composition which has a few overlaps.

The semantics of domain-membership-triple-record seem close to the musing gap2:

domain = [
    AEs: [ + environment-map ]
    ? name: environment-map
]

except the domain name is required and isn't currently described as an environment-map. Domain names as environment-map could be easily adjusted by: $domain-id-type-choice /= environment-map

The context in which a domain record exists isn't mentioned in musings. Possibly, it is added to concise-mid-tag? Alternatively, a comid tag is by default an unnamed domain and the environment-map statements for any triple implies domain membership. But to apply hierarchical relationships, a domain ID is needed. Possibly, comid should be extended to allow name declaration:

concise-mid-tag = {
  ? &(domain-id: x) => $domain-id-type-choice
}

[nedmsmith]

Closing gap 1. The domain-dependency-triple-record captures AE --> TE dependencies. The assumption is that a trust dependency across domains exists when domain membership consisting of TEs depends on a domain membership consisting of AEs.

attester = {
    AE: environment-map
    TEs: [ + environment-map ]
}

makes clear which TEs depend on which AE, but the dependency could involve multiple AEs (for example a multi-core CPU that hosts a workload that can be scheduled on any of the CPUs). Possibly, the relationship is many-many?

If a domain membership is constructed around AE vs TE groups, the domain-dependency triples would be sufficient.

[nedmsmith]

Regarding:

erDiagram
    "domain A" ||--|{ AE : "attesting environments"
    AE ||--|{ AK : "Attest keys"

It is possible that a domain only contains target environments. The attesting environment crosses a domain boundary. Domain B could have multiple TEs associated.

erDiagram
    "domain B" ||--|{ TE1 : "target environments"
    "domain B" ||--|{ TE2 : "target environments"

Domain B trust depends on Domain A

flowchart LR
    domA["Domain A"]
    domB["Domain B"]
    domA --> domB

The environments with attestation keys attest-key-triple-record and possibly identity-triple-record identify which environments are Attesting Environments. The evidence signed by the attestation key determines the scope of the AE-->TE dependency. In concise-evidence, virtually any triple could be signed. If the evidence target is logically an anonymous domain then it is seems reasonable to model dependency using domains. The triples within the domains determines the precise AE:TE mappings.

For an endorsement structure to model the evidence signing behavior, there needs to be a structure that describes which key signs which evidence or which AE (that has a key) signs which evidence domain.

flowchart LR
    domA["Domain A"]
    domB["Domain B"]
    domA -- signs or attests --> domB

A domain may have multiple AEs and an AE may have multiple AKs.

erDiagram
    "domain A" ||--|| AE1 : "attesting env 1"
    "domain A" ||--|| AE2 : "attesting env 2"
    AE1 ||--|| AK1 : "Attest key 1"
    AE2 ||--|| AK2 : "Attest key 2"
    AE2 ||--|| AK3 : "Attest key 3"

Hence, the domain containing AEs may need to model the key / keys that are expected to sign evidence. Domain A may contain an attestations-triple that explicitly defines the expected attested information.

attestation-triples = [
   AKs: [ AK2, AK3 ]
   TEs: [ "Domain B" ]
]

If any key associated with an AE can sign, then the AE can be used. If any key in the domain can sign, then the domain name can be used.

attestation-triples = [
   AKs: [ "Domain A" ]
   TEs: [ "Domain B" ]
]

Or:

attestation-triples = [
   AKs: [ AE1, AK3 ]
   TEs: [ "Domain B" ]
]

If different keys are to be used to attest different parts of the target domain. Then the TEs list may be something other than a domain name.

attestation-triples = [
   AKs: [ AK1 ]
   TEs: [ TE1 ]
]

Or:

attestation-triples = [
   AKs: [ AK3 ]
   TEs: [ TE2 ]
]

The current domain-dependency-triple-record implies this:

attestation-triples = [
   AKs: [ "Domain A" ]
   TEs: [ "Domain B" ]
]

Using a domain name or environment name instead of key identifier is helpful if the key is derived dynamically (as in DICE). The verifier is checking that the dynamic key belongs to an expected AE / attesting domain.

[thomas-fossati]

The semantics of domain-membership-triple-record seem close to the musing gap2:

domain = [
    AEs: [ + environment-map ]
    ? name: environment-map
]

except the domain name is required and isn't currently described as an environment-map. Domain names as environment-map could be easily adjusted by: $domain-id-type-choice /= environment-map

Yes, any similarity between the two wasn't purely coincidental :-)

The context in which a domain record exists isn't mentioned in musings.

Can you elaborate a bit on the exactly what does a context represent?

[thomas-fossati]

Closing gap 1. The domain-dependency-triple-record captures AE --> TE dependencies. The assumption is that a trust dependency across domains exists when domain membership consisting of TEs depends on a domain membership consisting of AEs.

attester = {
    AE: environment-map
    TEs: [ + environment-map ]
}

makes clear which TEs depend on which AE, but the dependency could involve multiple AEs (for example a multi-core CPU that hosts a workload that can be scheduled on any of the CPUs). Possibly, the relationship is many-many?

Ideally, I'd like to keep this as simple as possible -- i.e., in a tree rather than a full-blown graph. In the multi-core CPU / workload example you mention, the AE could be modelled as:

erDiagram
    "AE (CPU class)" ||--|{ "AE (CPU instance)" : has

which would allow us to keep the simple hierarchical structure:

erDiagram
    "AE (CPU class)" ||--|{ workload : contains

If a domain membership is constructed around AE vs TE groups, the domain-dependency triples would be sufficient.

That may indeed be the case.

[andrew-draper]

Are attesting environments (AE) important after they have performed their function?

I've been thinking of an AE as something which provides non-faked measurements of a Target Environment (TE). Once the TE has been proved non-faked then the AE is not required - it can be replaced with a token that summarizes it (for example by one of the keys which authorizes the keychain which signs TE measurements).

My take on composition is that there are two types of composition:

1. Layered composition, where the trustworthyness of an AE depends on the correctness of a TE
2. Grouping, where one TE makes statements about the relationships between other TEs

For Layering, we need a way for the rim to indicate that another TE must have been validated before this TE can be considered validated.

For Grouping, I don't have a proposal for how to encode this or which RIM it should go into

[nedmsmith]

AEs start out as TEs, but become AEs if they play a role in deciding which sets of measurements belong to which TEs. It seems incorrect to say that TE's may statements about other TEs unless the TE making the statement contains an AE.

The "grouping" concept is achieved by the AE algorithm that "collects" measurements and gives them a name or names (aka environment).

If an TE contains an AE, the dependent AE that collects its measurements determines if the AE subset has its own name or if it is named by the bounding TE name. For example, an AE might be composed of AE code and a DPE or TPM module. The combination of the code and the DPE/TPM allows the AE to perform attester tasks that include (a) measurement collection, (b) measurement reporting (signing), and maybe (c) measurement storage. A verifier might care about the security properties of the AE because they are security critical, so it may not be easily absorbed into the bounding TE, especially if the bounding TE has code that is less security relevant (and therefore has a different level of trust / trust policy). It makes sense for the TE to be modeled in terms of its component parts (e.g., bounding TE code, AE code, AE module). No TE (or AE inside a TE) speaks for itself. There is a lower layer AE (key) that speaks for its trustworthiness properties. In that sense, the lower layer AE creates the 'token' that summarizes it.

Based on this understanding of AE/TE dynamics, I'd say the correctness of a TE is observed by another AE. Since an AE is also a TE, there is correctness of an AE is observed by another AE until a root AE is reached.

The bounding TE is just a namespace that is common to all of its members. If an AE key generates a token that summarizes it, the summary offers information hiding abstraction, but not information elimination, as the AE inside the bounding TE may have trust differential from the non-AE components.

I agree there are two types of composition, but they are related by AE behavior (implementation) that decides the grouping of the next layer.