rfc9781v2.txt   rfc9781.txt 
skipping to change at line 154 skipping to change at line 154
using approved cryptographic, physical or procedural methods, using approved cryptographic, physical or procedural methods,
or a combination thereof." or a combination thereof."
For the purposes of the present document, we focus on a protected For the purposes of the present document, we focus on a protected
communication channel used for conveyance that can ensure the same communication channel used for conveyance that can ensure the same
qualities as a CWT without having COSE protection available, which qualities as a CWT without having COSE protection available, which
includes mutual authentication, integrity protection, and includes mutual authentication, integrity protection, and
confidentiality. (Replay protection can be added by including a confidentiality. (Replay protection can be added by including a
nonce claim such as Nonce (claim 10 [IANA.cwt]).) Examples nonce claim such as Nonce (claim 10 [IANA.cwt]).) Examples
include conveyance via PCIe (Peripheral Component Interconnect include conveyance via PCIe (Peripheral Component Interconnect
Express), IDE (Integrity and Data Encryption), or a TLS tunnel. Express) IDE (Integrity and Data Encryption) or a TLS tunnel.
All terms referenced or defined in this section are capitalized in All terms referenced or defined in this section are capitalized in
the remainder of this document. the remainder of this document.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
skipping to change at line 208 skipping to change at line 208
also the delegate to compose the Claim to be conveyed. Whether it 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 a transfer or transport, a Secure Channel is presumed to be used for
conveying such UCCS. The following sections elaborate on Secure conveying such UCCS. The following sections elaborate on Secure
Channel characteristics in general and further describe RATS usage Channel characteristics in general and further describe RATS usage
scenarios and corresponding requirements for UCCS deployment. scenarios and corresponding requirements for UCCS deployment.
3. Characteristics of a Secure Channel 3. Characteristics of a Secure Channel
A Secure Channel for the conveyance of UCCS needs to provide the A Secure Channel for the conveyance of UCCS needs to provide the
security properties that would otherwise be provided by COSE for a security properties that would otherwise be provided by COSE for a
CWT. In this regard, UCCS is similar in security considerations to CWT. In this regard, UCCS are similar in security considerations to
JWTs [BCP225] using the algorithm "none". Section 3.2 of RFC 8725 JWTs [BCP225] using the algorithm "none". Section 3.2 of RFC 8725
[BCP225] states: [BCP225] states:
| [...] if a JWT is cryptographically protected end-to-end by a | [...] if a JWT is cryptographically protected end-to-end by a
| transport layer, such as TLS using cryptographically current | transport layer, such as TLS using cryptographically current
| algorithms, there may be no need to apply another layer of | algorithms, there may be no need to apply another layer of
| cryptographic protections to the JWT. In such cases, the use of | cryptographic protections to the JWT. In such cases, the use of
| the "none" algorithm can be perfectly acceptable. | the "none" algorithm can be perfectly acceptable.
The security considerations discussed, e.g., in Sections 2.1, 3.1, The security considerations discussed, e.g., in Sections 2.1, 3.1,
skipping to change at line 238 skipping to change at line 238
initial algorithms specification [RFC9053]. initial algorithms specification [RFC9053].
Secure Channels are often set up in a handshake protocol that Secure Channels are often set up in a handshake protocol that
mutually derives a session key, where the handshake protocol mutually derives a session key, where the handshake protocol
establishes the (identity and thus) authenticity of one or both ends establishes the (identity and thus) authenticity of one or both ends
of the communication. The session key can then be used to provide of the communication. The session key can then be used to provide
confidentiality and integrity of the transfer of information inside confidentiality and integrity of the transfer of information inside
the Secure Channel. (Where the handshake did not provide a mutually the Secure Channel. (Where the handshake did not provide a mutually
secure channel, further authentication information can be conveyed by secure channel, further authentication information can be conveyed by
the party not yet authenticated, leading to a mutually secured the party not yet authenticated, leading to a mutually secured
channel.) A well-known example of a such a Secure Channel setup channel.) A well-known example of such a Secure Channel setup
protocol is the TLS [RFC8446] handshake; the TLS record protocol can protocol is the TLS [RFC8446] handshake; the TLS record protocol can
then be used for secure conveyance. then be used for secure conveyance.
As UCCS were initially created for use in RATS Secure Channels, the As UCCS were initially created for use in RATS Secure Channels, the
following section provides a discussion of their use in these following section provides a discussion of their use in these
channels. Where other environments are intended to be used to convey channels. Where other environments are intended to be used to convey
UCCS, similar considerations need to be documented before UCCS can be UCCS, similar considerations need to be documented before UCCS can be
used. used.
4. UCCS in RATS Conceptual Message Conveyance 4. UCCS in RATS Conceptual Message Conveyance
skipping to change at line 278 skipping to change at line 278
achieved if the sender and receiver mutually authenticate when achieved if the sender and receiver mutually authenticate when
establishing the Secure Channel. The quality of the receiver's establishing the Secure Channel. The quality of the receiver's
authentication and authorization will influence whether the sender authentication and authorization will influence whether the sender
can disclose the UCCS. can disclose the UCCS.
The extent to which a Secure Channel can provide assurances that UCCS The extent to which a Secure Channel can provide assurances that UCCS
originate from a trustworthy Attesting Environment depends on the originate from a trustworthy Attesting Environment depends on the
characteristics of both the cryptographic mechanisms used to characteristics of both the cryptographic mechanisms used to
establish the channel and the characteristics of the Attesting establish the channel and the characteristics of the Attesting
Environment itself. The assurance provided to a Relying Party Environment itself. The assurance provided to a Relying Party
depends on the authenticity and integrity properties of the Secure depends, among others, on the authenticity and integrity properties
Channel used for conveying the UCCS to the Relying Party. of the Secure Channel used for conveying the UCCS to the Relying
Party.
Ultimately, it is up to the receiver's policy to determine whether to Ultimately, it is up to the receiver's policy to determine whether to
accept a UCCS from the sender and to determine the type of Secure accept a UCCS from the sender and to determine the type of Secure
Channel it must negotiate. While the security considerations of the Channel it must negotiate. While the security considerations of the
cryptographic algorithms used are similar to COSE, the considerations cryptographic algorithms used are similar to COSE, the considerations
of the Secure Channel should also adhere to the policy configured at of the Secure Channel should also adhere to the policy configured at
each of end of the Secure Channel. However, the policy controls and each of end of the Secure Channel. However, the policy controls and
definitions are out of scope for this document. definitions are out of scope for this document.
Where an Attesting Environment serves as an endpoint of a Secure Where an Attesting Environment serves as an endpoint of a Secure
skipping to change at line 311 skipping to change at line 312
other unprotected data in the Verifier environment. If the receiver other unprotected data in the Verifier environment. If the receiver
subsequently forwards UCCS, they are treated as though they subsequently forwards UCCS, they are treated as though they
originated within the receiver. originated within the receiver.
The Secure Channel context does not govern fully formed CWTs in the The Secure Channel context does not govern fully formed CWTs in the
same way it governs UCCS. As with EATs (see [RFC9711]) nested in same way it governs UCCS. As with EATs (see [RFC9711]) nested in
other EATs (Section 4.2.18.3 (Nested Tokens) of [RFC9711]), the other EATs (Section 4.2.18.3 (Nested Tokens) of [RFC9711]), the
Secure Channel does not endorse fully formed CWTs transferred through Secure Channel does not endorse fully formed CWTs transferred through
it. Effectively, the COSE envelope of a CWT (or a nested EAT) it. Effectively, the COSE envelope of a CWT (or a nested EAT)
shields the CWT Claims Set from the endorsement of the secure shields the CWT Claims Set from the endorsement of the secure
channel. (Note that an EAT might add a nested UCCS Claim, and this channel. (Note that a nested UCCS Claim might be added to EAT, and
statement does not apply to UCCS nested into UCCS; it only applies to this statement does not apply to UCCS nested into UCCS; it only
fully formed CWTs.) applies to fully formed CWTs.)
5. Considerations for Using UCCS in Other RATS Contexts 5. Considerations for Using UCCS in Other RATS Contexts
This section discusses two additional usage scenarios for UCCS in the This section discusses two additional usage scenarios for UCCS in the
context of RATS. context of RATS.
5.1. Delegated Attestation 5.1. Delegated Attestation
Another usage scenario is that of a sub-Attester that has no signing Another usage scenario is that of a sub-Attester that has no signing
keys (for example, to keep the implementation complexity to a keys (for example, to keep the implementation complexity to a
 End of changes. 5 change blocks. 
8 lines changed or deleted 9 lines changed or added

This html diff was produced by rfcdiff 1.48.