[Rats] Re: Iotdir early review of draft-ietf-rats-msg-wrap-04

[Thomas Fossati <[e-mail]>]

Hi Mohit,

Thanks a lot for your comments.

On Sun, 26 May 2024 at 13:05, Mohit Sethi via Datatracker
<[e-mail]> wrote:
> * Section 4: Perhaps expand what is CoRIM and add a reference to
> https://datatracker.ietf.org/doc/html/draft-ietf-rats-corim-04

ack, done.

> * 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.

In the typical case, CMWs found in certs (and CSRs) carry evidence
about a target environment associated with the (to be) certified
keypair.
In CRLs, CMWs can be used to describe "known-bad values" associated
with the revoked DICE cert - sort of "anti" reference-values :-)

> 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?

The motivating use cases are explained in Section 6.1 of DICE
Attestation Architecture [1] and in the CSR-attestation document.  My
preference would be to provide clear references to those two docs
rather than restating the content here.  In that sense I reckon the
first paragraph of Section 5 can be improved a bit.

[1] https://trustedcomputinggroup.org/wp-content/uploads/DICE-Attestation-Architecture-Version-1.1-Revision-17_1August2023.pdf

> * 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.

I think you are right, they should be fully aligned.
Ned is the chair of the DICE WG in TCG, so he's the authoritative
voice wrt this point.

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

done

> Note: I haven't verified the CDDL, CBOR, and JSON for correctness via tooling,
> but they looked fine while reading.

I have just run "make -C cddl" and everything seems in order.

Thanks again, cheers!