Carl's review (https://mailarchive.ietf.org/arch/msg/rats/xY2mwu790UOGnhFAUduGj5ddo3Y/)

"In section 5, it may be worth calling out that the encoded CMWCollection is encoded as an OCTET STRING as the extnValue field of this extension. Section 4.2 in RFC5280 makes this point but I’ve seen the outer OCTET STRING left out in a couple of attestation-related contexts. The pseudo code about removing “the ASN.1 OCTET STRING” in Section 3.3. could further this misimpression since there are two OCTET STRING layers wrapping a CBOR value. Maybe add something like: “The DER encoded CMWCollection is the value of the octet string for the extnValue field of the extension”."

Email from @cabo:

The CDDL rule RFC6383 doesn’t quite mirror what RFC 6383 actually says.
You put in a new rule for suffixes, but the way you are using “+”, these will become part of the restricted-name; maybe you need to take out

   restricted-name-chars =/ "+" ; Characters after last plus always
                                ; specify a structured syntax suffix

We've been informed that instead of making an early allocation in the registry at https://www.iana.org/assignments/media-types, we would need to add these to the provisional standard media type registry at https://www.iana.org/assignments/provisional-standard-media-types.

When the document is approved for publication, we would remove those entries from the provisional registry and add them to the media type registry itself.

Is it OK with the CMW authors for the pre-allocation request to be modified to target the Provisional Standard Media Type Registry?

To help understanding what are the (registration) preconditions for using a specific CMW format, it may be useful to stick the picture below somewhere.

        .-------------.    .---------.
       | Reuse EAT     |  | Register  |
       | media type    |  | new media |
       | + eat_profile |  | type      |
        `--+----+-----'    `-+----+--'
           |    |            |    |
           |  .-+------------+-.  |
           | |  |  Register  |  | |
         .-(-+-'   new CoAP   `-+-(-.
        |  | |  Content-Format  | |  |
        |  |  `-------+--------'  |  |
        |  |          |           |  |
        |  |          v           |  |
        |  |   .--------------.   |  |  .--------.
        |  |  | Automatically  |  |  | | Existing |
        |  |  | derive CBOR    |  |  | | CBOR     |
        |  |  | tag [RFC9277]  |  |  | | tag      |
        |  |   `------+-------'   |  |  `---+----'
        |  |          |           |  |      |
        |  |          |.----------(--(-----'
        |  |          |           |  |
        |  |          v           |  |
        |  |   .----------------. |  |
        |  |  /  CBOR tag CMW  /  |  |
        v  v `----------------'   v  v
    .--------------------------------------.
   /             Array CMW                /
  `--------------------------------------'

@henkbirkholz has the following comments regarding prose in §3.4:

• #45 (comment)
• #45 (comment)
• 8c5dcc3#r1465272666

Discussion starting here:

• https://mailarchive.ietf.org/arch/msg/rats/eFBCC1JxC573SkDSp6yWZ4J_dyM/

We may want to define CMWCollection with finer granularity, e.g.:

CMWCollection ::= CHOICE {
    json UTF8String,
    cbor OCTET STRING,
}

The document should define an application/cmw media type to be used when CMWs are carried by transports that use media types to identify their payloads. E.g.:

POST /verify HTTP/1.1
Host: verifier.example
Content-Type: application/cmw+json

[
  "application/eat+jwt",
  "eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9..."
]

Note that #39 should provide a similar application/cmw-collection media type to be used for composite evidence formats that use a CMW collection as their encapsulation:

POST /verify HTTP/1.1
Host: verifier.example
Content-Type: application/cmw-collection+json

{
  "cpu": [
    "application/eat+jwt",
    "ZXlKaGJHY2lPaUpGVXpJMU5pSXNJblI1Y0NJNklrcFhWQ0o5Lg..."
  ],
  "gpu": [
    "application/ucs+json",
    "eyJlYXRfbm9uY2UiOiAiamtkOEtMLTg9UWx6ZzQifQ"
  ]
}

On AMD SEV-SNP, every machine has its own attestation-signing key that is cached on the node. The VMM is permitted to give the certificate to the guest in an "auxblob" as a means of avoiding a runtime dependency on a low query-per-second (QPS) service that provides the certificates given data that is available in the attestation reports (product, CHIP_ID and TCB_VERSION).

To help out the attestation verification service, we pass that certificate along to allow it to avoid its own fetch from a cache. My thinking was that we'd put this in the CMW under an x509 certificate content type (application/pem-certificate-chain maybe? application/x-x509-ca-cert seems like a misnomer) but with an indicator that it's an attestation key certificate, or as an endorsement with a new content type that I negotiate with AMD to register with the IANA.

Is cached certificate collateral for helping interpret evidence... reference value? Endorsement? Or some new indicator? If AMD were to write its certificate provisioning service with CoRIM in mind, they might provide their x.509 certificate in a corim's cose headers, where the corim just describes the data that are currently in the x.509 extensions https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/57230.pdf. I'm guessing since there's no reference or endorsement triple involved in giving the attestation key data... it's a new indicator?

See https://mailarchive.ietf.org/arch/msg/rats/Bmlxnu0GmnRMsP6WEq3CBjLVm0k/

IANA is not allowed to create a new registry and create pre-allocation entries.

RFC 7120 allows for early allocations from existing registries (with chair and AD approval, or just AD approval if the document is AD-sponsored), but it doesn't permit the early creation of registries.

We are looking at how to make this work for a 7120bis (no text yet), which we'll be discussing with the IESG in Vancouver, but that's not very helpful at the moment. (Logistical issues include what to do with abandoned registries given that we prefer not to delete them, whether intended registration procedure should affect the early registration procedure, and how allocations from yet-to-be-approved documents should be carried over when the IESG approves the document that contains the registry.)

In the meantime, the two options available would probably be to 1) include any other drafts' registrations in the document that contains the registry, and use a "reference" field to refer to those other drafts, or 2) limit the registrations in the I-D version of the registry as desired, but have the WG maintain a living registry of some kind in a wiki or in github that can contain entries for other documents. In the latter case, it would be important to make sure that nobody can add entries to that living pre-registry once IANA creates the actual registry.

IANA expert also asked the CMW authors to add the following text to the IANA section, table 2, for this registry:
"4-255 | Unassigned".

I'm having trouble determining which content type to suggest for any of the evidence formats I'm working with, given that they're all binary formats specified by vendors or the TCG. Is the intention for AMD, Intel, TCG, and CNCF to all apply for application content types for formats they will specify themselves? I wouldn't want to say application/cbor for binary that doesn't have the major type tag for CBOR bytes, for example. The ind field is for hinting at the expected interpretation of the underspecified media type, so it'd be nice to have an appropriate underspecified media type that is basically "binary evidence for RATS". The examples use undefined example media types and the application/eat+jwt type, but nothing prior to attestation results that can be sent to a remote attestation verifier.

I'd say we should encourage folks to avoid using cmw-collection labels as "standard" ways to interpret the data carried in the value, but while a format is developed for a new form of attestation, it'd be nice to have a kind of catch-all for underspecified binary evidence content.

CMWs aren't necessarily signed which means the CMW could be included inside of a signed container. For example, a CMW certificate extension allows the CMW to be signed via an X.509 certificate.

A CWT is also a signed container that could contain a CMW. However, there isn't a CWT registry entry for CMW.

This issue proposes adding an IANA Considerations section:

IANA is requested to allocate the following tags in the "CWT Claims" registry, preferably with the specific CWT Claim value requested:

The document says:

"When using JSON, the value field is encoded as Base64 using the URL and filename safe alphabet (Section 5 of RFC4648) without padding."

we should add a note saying that the base64 encap always applies, even if the evidence format is already textual (e.g., a JWT).

Since #67 a CMW can also be a collection.

But now we have introduced a slight asymmetry: the typing mechanism we have for non-collection CMWs does not apply to collections, i.e., collections don't have an intrinsic way to describe their overall type.

Clearly, one can always define the media type of a given collection, but that's an extrinsic property and is not always useful.

Problems linked to this asymmetry have popped up in the use of CMW collections with the X.509 wrapper where the OID is not a sufficient indication for the processor to make sense of the wrapped CMW collection as a whole.

One possibility is to reuse the EAT approach and reserve a specific label for a type indicator, e.g.:

json-collection = {
  ? "__cmwc_t": uri / oid
  + text => json-CMW / c2j-tunnel
}
cbor-collection = {
  ? "__cmwc_t": uri / oid
  + (int / text) => cbor-CMW / j2c-tunnel
}

(Note the use of CDDL's cut in the definition which prevents further matching on the same "reserved" label.)

Note that we could derive automatic media types using the base application/cmw+cbor (or application/cmw+json) and add a t parameter with the value of the __cmwc_t key.

Given a use case for an attestation results or other message that conveys other CMs that are relevant to a particular attestation result. Does it make sense to continue following the convention of using tagged cbor - as in:

tagged-cmw-record = #6.4711(bytes .cbor cmw-array)

A possible triple record structure that treats other CMs as triple objects might be:

ar-triple-record = [ 
     attester: stateful-environment-map,
     ar-claims: [ + $ar-claims-type-choice ] 
]
$ar-claims-type-choice /= tagged-cmw-record

The argument against is that cmw-array already has tagged values and the little bit of CDDL inside of ar-claims: isn't enough to warrant needing a CBOR tag.
The argument for is that all $ar-claims-type-choice possibilities are expected to be tagged-xxx values that can be dispatched by a parser dispatcher following a consistent convention.

Current work in TCG DICE and IETF "attested CSR" requires embedding CMWs in X.509 artefacts (certs and CSRs).

We should register the relevant OIDs with IANA.

• In the third sentence of intro, message should be plural
• The definition of RFC6838 in the CDDL looks to be incomplete
• Re: suffixes, I was assuming certificate extension support would use the DER/BER values. What about CRL extensions? Is PEM needed as well?
• The structured suffix link in Section 3.1 is broken.
• Maybe reference EAT media types spec as initial values of interest.

This is a left over from #14

Re: suffixes, I was assuming certificate extension support would use the DER/BER values. What about CRL extensions? Is PEM needed as well?

Laurence email to [email protected]:

Maybe some clarification about the use of the CWT claim to carry the conceptual message? If the CWT is an EAT and the conceptual message is an EAT, you have an EAT in an EAT and it looks a lot like a nested token. But I don’t think that’s what is intended at all. The surrounding EAT in this case is just convenient transport. It is not binding to or attesting to the enclosed EAT.
One way to do this would for the examples to be more expansive.

Composite and layered attesters produce evidence that can be composed of multiple individual evidence "bits".

A CMW "collection" is a container that aggregates several CMW evidence "bits," each with its unique "name."

cmw-collection = {
  + (int / text) => cmw
}

where

cmw = cmw-array / cmw-cbor-tag<bytes>

Note that this proposal addresses roughly the same scope as @SimonFrost-Arm's EAT collections, and intentionally makes a very similar serialisation.

The abstract has too much details, whilst the intro is lightweight on the tech front. I suggest we move most of the abstract contents to the bottom of the intro.

There has been a discussion thread related to adding cm-type to the CMW array / record as a way to indicate which RATS conceptual messages are behind the wrapper. The following CDDL is suggested:

cmw = [ type, value, cm-bits ]
cm-bits = uint .bits cm-type
cm-type = &(
                reference-values: 0
                endorsements: 1
                evidence: 2
                attestation-results: 3
}

The justification for cm-bits is that a conceptual message structure could contain more than one type of conceptual message. For example a corim could contain conditional endorsed values given a stateful environment-map. Additionally, it could contain trust anchor stores, or attestation results and all of the conceptual messages that were used as Verifier inputs.

I'm confused by cmw-start.cddl and cmw.cddl. Each has a definition for cmw. frags.mk ignores cmw.cddl so possibly removal of cmw.cddl is needed? However, I prefer the convention that the "start" file contains only the start directive. This makes it easy to replace with a different start vector for debugging purposes. It would be better to put the cmw definition in cmw.cddl and include it in the frags.mk IMHO.

Mohit's IoT directorate review

Some minor comments:

• Section 4: Perhaps expand what is CoRIM and add a reference to https://datatracker.ietf.org/doc/html/draft-ietf-rats-corim-04

• Section 5 and 5.1: It would be helpful for readers if a short use-case explaining when CMW would be transported in CRLs could be provided. While I can guess why a CMW would be in a CSR, I could not immediately understand when a CMW would be part of a CRL. Similarly, it would be helpful to explain where and how the ASN.1 module will be used. I assume it is relevant for cases where a certificate containing a CMW extension is passed around?

• Section 5.2: I wonder about the consequences of having two different CMW specifications: one by the Trusted Computing Group (TCG) and the other in this draft. I downloaded the TCG specification and found a reference to this draft. Would it be possible for future versions of the TCG specification to reuse this draft rather than creating a subset? Also, this draft states that the "CMW extension" "MUST NOT be marked critical," whereas the TCG specification states that the "tcg-dice-conceptual-message-wrapper extension criticality flag SHOULD be marked critical." In summary, I wonder if these specifications can somehow be synchronized.

• Section 7: Please expand UCCS on first use: unprotected CWT Claims Sets (UCCS).

UCCS is not protected

In https://mailarchive.ietf.org/arch/msg/rats/xY2mwu790UOGnhFAUduGj5ddo3Y/ Carl notes:

"The security considerations section says that “messages themselves and their encoding ensure security protection.” This is not true for UCCS, which is part of the referenced EAT media type spec."

Intra-element binding in collections

In a private conversation between Ned and I:

"[t]here should be a way to ensure the integrity of the collection as soon as the collection is formed.".

Re: intra-element binding, see also: https://www.ietf.org/archive/id/draft-frost-rats-eat-collection-03.html#section-4.1

The Abstract/Introduction sections are fairly thin - we should add more details about the expected use cases.

We need to define how to deal with CBOR tags that exist independently of a CoAP C-F.

Comment from Mike Jones:

"I believe that Section 3.1 needs to be revised to say that the json-record is the value of the "cwm" JWT claim and the cbor-record is the value of the "cwm" CWT claim."

I'm noodling through the idea of a modular evidence collection daemon that just runs installed binaries in a certain location and assembles a cmw-collection together to send off, and I'm wondering how much interpretation of the output it would need, assuming all the binaries output a legal CMW of either CBOR or JSON encoding.

When JC<> is used, it's only when the CDDL pun breaks down and you need base64 encoding for binary. If you have your cmw-collection as a CBOR map, and we can use, say, the basename of the evidence collection binary to key the result, but the result is just bytes that are either CBOR or JSON, that doesn't seem to fit into the "cmw is either CBOR or JSON".

It seems that certainly a JSON cmw-collection that contains a CBOR-encoded cmw does not parse unless you're allowed to wantonly swap your interpretation of the CDDL as for JSON or CBOR as you see fit (say with the decapsulation algorithm), given that cmw doesn't have a base64 encoded string alternate to store a CBOR-encoded cmw.

Can we say that

cmw-collection = {
  + cmw-collection-entry-label => cmw
}

should be

cmw-collection = {
  + cmw-collection-entry-label => cmw-decap
}
cmw-decap = JC<jc-cmw, bytes .cbor cmw>
jc-cmw = cmw / base64-cmw
base64-cmw = base64-string .cbor cmw

I'm unsure if the .cbor control operator is allowed to be applied to a base64-string technically it's for byte strings and since "one can use CDDL with JSON by limiting oneself to what can be represented in JSON. Roughly speaking, this means leaving out byte strings"

I don't think we can use bytes .cbor cmw without inserting the major type byte 0x04 before the output of any of the evidence modules, so do we just define a .feature cmw-decap to apply the decap algorithm to arbitrary bytes instead of this JC stuff?

In order to avoid misunderstandings, it'd be beneficial to describe the encap/decap algorithms in a more explicit manner

The name id-pe-cmw-collection is not a great choice: a CMW can be a record, a tag or a collection, so emphasising "collection" seems unwarranted.

I propose we use id-pe-cmw instead.

Policies (for evidence and attestation results) as well as trust anchors are other CMs that we may want to support.

We should think whether we want the CM-IND bitmask to be extensible - e.g., via

cm-type /= &(
  yacm: bit_position
)

or we just capture all the existing CM in the RATS architecture and seal it once and for all.

1. do I trust this party to create a measurement (this isn't that important, I suspect, as we should always verify!)
2. do I trust this party to verify the measurement?
3. do I trust this party to attest to another party (or possibly the linkage to another party)?
4. do I trust this party to create a topology of trust relationships?

These are clearly different trust contexts, but people don't understand very well that contexts must be separated, so we should call this out and ensure that the semantics we're creating support them from the very initial version and any implementation (or people will combine them, and implementations will allow combinations to support previous versions, which is a Bad Thing[tm]).

The IANA considerations section should be filled out to describe the requirements for defining, describing, and registering the media type formats that would be used within the wrapper.

IANA experts feedback: I believe that Section 3.1 needs to be revised to say that the json-record is the value of the “cwm” JWT claim and the cbor-record is the value of the “cwm” CWT claim.

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?

@ounsworth commented on the CMW extension:

§6.3 of draft-ietf-lamps-csr-attestation-08 defines a new registry: "SMI Security for PKIX Evidence Statement Formats" which might be a better place to put it?

Since CMW is not evidence-only, the name of the CSR-attestation registry should be probably tweaked to match the extended semantic.

cc @mcr

At present, we don't. However, while we are at it, it probably makes sense.

We use the JC CDDL macro, but we don't define it.

We need to add:

JSON-ONLY<J> = J .feature "json"
CBOR-ONLY<C> = C .feature "cbor"

JC<J,C> = JSON-ONLY<J> / CBOR-ONLY<C>

maybe in a "conglomerate" CDDL -- (That, or use a CDDL 2 import directive.)

Carl, about #78 :

'I read the PR but can't say that it helps much. The phrase "If a label changes Verifier state beyond a "hint"" must be evaluated from the point of view of a verifier, right? If different verifiers may elect to use or ignore a "hint", I don't see how this could be any other way. The rest of that sentence establishes that how a verifier acts upon a "hint" determines whether a label is considered to carry semantic content. This impacts the next sentence, which states that "the collection SHOULD be signed by an attestation key" when a label carries semantic content. Maybe stating "if an attester expects for a label to change Verifier state beyond a "hint"" would salvage the paragraph. Separately, is "label" right here or should it be "item" or "message"? It might also help if "hint" were defined in this context as well as how the "hint" notion interacts with the last point made in the security considerations section.'

In Table 2 in 7.4.2 shouldn't it be "Endorsement"? It's just one endorsement per conceptual message, right?

Ref values is correct as plural. Evidence is fine too.

Attestation Results could be singular, but seems OK plural.

Should include “This document does not require any IANA actions.”
discuss if normative for authors should exist here.

We should change the cmw-array to cmw-record so people don’t get the wrong impression that cmw-array is an array of cmw.

A cmw-collection might be an appropriate name for an array of cmw.

(These points were originally raised by @nedmsmith)

Remove Claim Value Type(s): JSON Object or JSON Array should be removed since JWT registry doesn't have this field defined.

The newly added PKIX extension(s) should be mentioned in the abstract and introductory text.

RFC9193 provides an excellent glossary for all things "media types". We should stick to that.