Change:
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

Discussion:
This specification allocates a CBOR tag to mark Unprotected CWT Claims Sets (UCCS) as such and discusses conditions for its proper <del> use in the scope of Remote Attestation Procedures (RATS) in the usage scenario that is the conveyance of Evidence from an Attester to a Verifier. </del> <ins> use in the scope of Remote Attestation Procedures (RATS RFC9334) in the usage scenario that is the conveyance of Evidence from an Attester to a Verifier. </ins> This specification does not change RFC8392: A true CWT does not make use of the tag allocated here; the UCCS tag is an alternative to

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.

the UCCS through the Secure Channel to the lead Attester.  The lead Attester then computes a cryptographic hash of the UCCS and protects that hash using its signing key for Evidence, for example, using a <del> Detached EAT Bundle (I-D.ietf-rats-eat). </del> <ins> Detached-Submodule-Digest or Detached EAT Bundle (I-D.ietf-rats-eat). </ins> 4.3.

secchan discusses security considerations for Secure Channels, in which UCCS might be used.  This document provides the CBOR tag definition for UCCS and a discussion on security consideration for <del> the use of UCCS in Remote Attestation Procedures (RATS).  Uses of UCCS outside the scope of RATS are not covered by this document.  The UCCS specification - and the use of the UCCS CBOR tag, correspondingly - is not intended for use in a scope where a scope- specific security consideration discussion has not been conducted, vetted and approved for that use. </del> <ins> the use of UCCS in RATS.  Uses of UCCS outside the scope of RATS are not covered by this document.  The UCCS specification - and the use of the UCCS CBOR tag, correspondingly - is not intended for use in a scope where a scope-specific security consideration discussion has not been conducted, vetted and approved for that use. </ins> 6.1.