Draft: draft-ietf-rats-uccs

Commentary: Archived - At : 
 straight forward . : ship : it !
Mailing list commentary: 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 = # 6.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 ( like RFC5911 and 5912 did for ) , and then have future specs only define new things . Dear RATS WG , this I - D should now be ready for WGLC . ,
Paragraph (version A):
This specification allocates a CBOR tag to mark Unprotected CWT
Claims Sets (UCCS) as such and discusses conditions for its proper
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.
Paragraph (version B):
This specification allocates a CBOR tag to mark Unprotected CWT
Claims Sets (UCCS) as such and discusses conditions for its proper
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.
Paragraph (version A):
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.
Paragraph (version B):
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.
Paragraph (version A):
Another usage scenario is that of a sub-Attester that has no signing
keys (for example, to keep the implementation complexity to a
minimum) and has a Secure Channel, such as a local IPC, to interact
with a lead Attester (see Composite Device, RFC9334).  The sub-
Attester produces a UCCS with the required CWT Claims Set and sends
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
Detached EAT Bundle (I-D.ietf-rats-eat).
Paragraph (version B):
Another usage scenario is that of a sub-Attester that has no signing
keys (for example, to keep the implementation complexity to a
minimum) and has a Secure Channel, such as a local IPC, to interact
with a lead Attester (see Composite Device, RFC9334).  The sub-
Attester produces a UCCS with the required CWT Claims Set and sends
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
Detached-Submodule-Digest or Detached EAT Bundle (I-D.ietf-rats-eat).
Paragraph (version A):
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
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.
Paragraph (version B):
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
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.