Add prose for example meanings of labels in cmw-collection

[deeglaze]

I had asked before if we could make the labels of the cmwc non-semantic because of the aggregation issue, and now I'm wondering about how we connect this with something like tls-attestation. The only notions of evidence are the media types, so each is inherently understood to be unique to the form of evidence.

Here's an example: Both Intel TDX and AMD SEV-SNP have their attestation reports made available through the Linux configfs-tsm system. If we are to create a media type like application/vnd.linux.configfs-tsm, then the two forms of attestation report that SEV can give through that interface would be indistinguishable. We have the raw attestation report from the AMD SP, and we have the service attestation reports that are either individual or a manifest of all available services. There's reason to collect multiple reports for the same connection given the different services and necessary service versions. The disambiguation here makes sense as a reason to have labels, but it's not clear in the text.

Having said that, I don't know how to say, "I can give you service evidence in application/vnd.linux.configfs-tsm format, and I can give you a raw attestation in application/vnd.linux.configfs-tsm format." with evidence_propose, similarly there is no way to request a specific evidence form from the other side.

If the content type has to uniquely identify the content for propose/request, I don't see a reason to have labels or ind. If it's not meant to uniquely identify the content for propose/request, then tls-attestation needs to be amended to allow for label-based disambiguation. I don't see a reason to add label-based disambiguation to the TLS extensions if we keep the integer type for CBOR keys, since the JSON vs CBOR format request shouldn't matter to the TLS protocol, right?

[nedmsmith]

application/vnd.linux.configfs-tsm

Wouldn't a vendor-specific evidence type be chosen by the vendor that produced it, for example: application/vnd.tdx? Would an OS process re-wrap the content with a different vendor-defined media type or would the signer of the content be the most appropriate entity to decide which media type to use?

[thomas-fossati]

application/vnd.linux.configfs-tsm

Wouldn't a vendor-specific evidence type be chosen by the vendor that produced it, for example: application/vnd.tdx?

I'd have thought the same. Why would the TSM backend not return its native media type?

[deeglaze]

We could do that, though not everything is signed. There's the service manifest for example, that when you request a service attestation, you get SHA-512(nonce || service manifest) as the new nonce in an attestation report at a higher privilege level than the guest itself can request for a raw attestation. This is all beside the point that the labels themselves aren't doing favors for discovery and request protocols.

[nedmsmith]

the labels themselves aren't doing favors for discovery and request protocols

Was this usage anticipated by the cmw work? I thought the originator (signer?) of the message selects the label based on their understanding of the contents and organization of the various cmws rather than on presumed usage(s). In many cases, there could be many usages the content originator hopes to support, and wouldn't be in a position to try to accommodate all of them.

However, using cmw for discovery and request protocols is an interesting use case on it's own. Possibly, it is just another layer of indirection and cmw is flexible enough to support multiple layers of indirection.

[deeglaze]

What are its existing usages then?

"With the CMW format described in this document, protocol designers do not need to update protocol specifications to support different conceptual messages."

I don't know what the expected usage of a label is for protocols to consume them.

[thomas-fossati]

Labels are identifiers within a given collection that, in principle, have no absolute/global significance. They are dependent on the usage of a collection payload within a protocol context.

If one is using CMW in protocol X, one could attribute specific semantics to labels that would be interpreted in a precise way within X.

[thomas-fossati]

"With the CMW format described in this document, protocol designers do not need to update protocol specifications to support different conceptual messages."

This only means that protocols that use CMWs don't need to update anything if (e.g.) a new evidence format is added.

[nedmsmith]

9334 says: "The lead Attester collects Evidence from other Attesters and conveys it to a Verifier. Collection of Evidence from sub-entities may itself be a form of Claims collection that results in Evidence asserted by the lead Attester. The lead Attester generates Evidence about the layout of the whole composite device, while sub-Attesters generate Evidence about their respective (sub-)modules." From a cmw context, the collection of Evidence needs to be bundled up in some fashion. The lead Attester is presumed to know enough about device composition to create the bundle. The cmw-collection structure from draft-ietf-rats-msg-wrap seems to fit this use case. The label then is a hint that helps the Verifier decide which cmw to crack open first, etc. Maybe the design of the Verifier ignores the label since it expects to crack open all of them? A different Verifier, say one that supports a profile, might use the label to encode the name of one of the sub-attesters and direct Evidence from that sub-attester to a subroutine that is tuned for that type of attester?

[nedmsmith]

If one is using CMW in protocol X, one could attribute specific semantics to labels that would be interpreted in a precise way within X.

This use case assumes the protocol endpoint is also the creator of the cmw message. In a composite device architecture, this may not be the case for all cmws that are generated by the device.

[deeglaze]

The lead Attester is presumed to know enough about device composition to create the bundle.

I think that it has information that can be discovered by enumerating subattesters in an install directory, but not intimate knowledge that subattesters will have. If we're putting significance on labels for verifiers to interpret as they see fit, I'm still a bit at a loss why CBOR is allowed to use integer keys when JSON can only use strings. The serialization choice is confusing. At least for the int in type: in CBOR has a specific meaning that translates through registered CoAP values to the normal Content-type string. For labels it's so open-ended that you may end up with it carrying way more semantic content than one would hope it to carry.

Perhaps I'm reading too deeply into the close symmetries between CMW and the TLS extensions from the tls-attestation draft and it's the TLS attestation doc that should be revised. Still, is there any proposed use of labels so far that uses them for semantic content? Your responses don't suggest as much. Thomas, do you have an existence proof for your protocol X?

[thomas-fossati]

The lead Attester is presumed to know enough about device composition to create the bundle.

I think that it has information that can be discovered by enumerating subattesters in an install directory, but not intimate knowledge that subattesters will have.

A generic lead attester, like the "evidence collection daemon" (ecd(8) for short), has to have some way to discover its subattesters' arrangement. Either via static configuration or some form of dynamic discovery (e.g., the one you suggest above).

This arrangement is going to be reflected in the CWM collection labelling, which is one facet of the ecd(8)'s external-facing interface, i.e., its "protocol".

In my fantasy, the protocol objects returned by ecd(8) are EAT containing the CMW collection as one of the claims, e.g.:

{
  "cmw": {
    "cpu.0": [
      "application/vnd.A",
      "..."
    ],
    "gpu.0": [
      "application/vnd.B",
      "..."
    ],
    "nic.0": [
      "application/vnd.C",
      "..."
    ],
    "nic.1": [
      "application/vnd.D",
      "..."
    ]
  },
  "iss": "ecd v0.0.1",
  "exp": 2024129268,
  "eat_profile": "tag:github.com,2024:deeglaze/ecd"
}

[deeglaze]

I'm confused. My understanding is that EAT is a representation of attestation results, which comes after the appraisal of evidence. I'm concerned with transmitting evidence to the verifier to then turn into attestation results that would be wrapped in an EAT to send along to the RP.

The "Taming attestation for the cloud native world with Parsec" talk Paul pointed me to says their model also expects to only send along a CMW (around 21 minutes in) https://youtu.be/NJKi3O0hhPo?si=P3_vimu4gUgKckWt&t=1280

[thomas-fossati]

I'm confused. My understanding is that EAT is a representation of attestation results, which comes after the appraisal of evidence.

No, EAT is a generic data format for attestation-related claims-sets, including Evidence (e.g., PSA) and Attestation Results (e.g., EAR).

[thomas-fossati]

@deeglaze, is there anything actionable related to this issue?

If so, could you please suggest some text?

If not, could this be closed?

[deeglaze]

I'll suggest some text.