Change:
2. <del> Usage scenarios involving the conveyance of Claims, in particular, Remote Attestation Procedures (RATS, see RFC9334) require a standardized data definition and encoding format that can be transferred and transported using different communication channels. As these are Claims, RFC8392 is a suitable format.  However, the way these Claims are secured depends on the deployment, the security capabilities of the device, as well as their software stack.  For example, a Claim may be securely stored and conveyed using a device's Trusted Execution Environment (TEE, see I-D.ietf-teep-architecture) or a Trusted Platform Module (TPM, see TPM2).  Especially in some resource constrained environments, the same process that provides the secure communication transport is also the delegate to compose the Claim to be conveyed.  Whether it is a transfer or transport, a Secure Channel is presumed to be used for conveying such UCCS.  The following sections elaborate on Secure Channel characteristics in general and further describe RATS usage scenarios and corresponding requirements for UCCS deployment. </del> <ins> Usage scenarios involving the conveyance of Claims, in particular RATS, require a standardized data definition and encoding format that can be transferred and transported using different communication channels.  As these are Claims, RFC8392 is a suitable format. However, the way these Claims are secured depends on the deployment, the security capabilities of the device, as well as their software stack.  For example, a Claim may be securely stored and conveyed using a device's Trusted Execution Environment (TEE, see I-D.ietf- teep-architecture) or a Trusted Platform Module (TPM, see TPM2). Especially in some resource constrained environments, the same process that provides the secure communication transport is also the delegate to compose the Claim to be conveyed.  Whether it is a transfer or transport, a Secure Channel is presumed to be used for conveying such UCCS.  The following sections elaborate on Secure Channel characteristics in general and further describe RATS usage scenarios and corresponding requirements for UCCS deployment. </ins> 3.

Discussion:
Archived-At:
straight forward. :ship: it! A few comments/questions for WGLC: The secure channel definition in section 1.1 may benefit from stating that mutual authentication is not required. This is hinted at by stating "the same qualities" as CWT conveyance are required but, given the NIST definition requires mutual auth, additionally saying mutual auth is not required would be clearer.In section 3.1.2, perhaps change the end of the last sentence to "using a Detached-Submodule-Digest or Detached-EAT-Bundle" since the Detached-Submodule-Digest is what conveys the hash and can be used independent of a Detached-EAT-Bundle.In Table 1 in Section 4, should the Data Item be Claims-Set instead of map? The registry is inconsistent. Some definitions are general with only map or array listed, others identify a specific type, e.g., the COSE types.There is a TODO in Appendix A and a note to insert definitions from 9052.The CDDL should include the tag definition that is the focus of this draft, something like: UCCS = .TBD601(Claims-Set) Independent of this draft, many current specs that use CDDL (including this one) repeat definitions that appear elsewhere. Perhaps it is close to time to discontinue this practice, publish an I-D or two that provide CDDL definitions for specs that predate CDDL (like RFC5911 and 5912 did for ASN.1), and then have future specs only define new things. On 1/11/23, 1:27 PM, "RATS on behalf of Henk Birkholz" on behalf of EMAIL > wrote: Dear RATS WG, this I-D should now be ready for WGLC. Viele Grüße, Henk RATS mailing list EMAIL URL