Found 1 record.

Status: Reported (1)

RFC 9202, "Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE)", August 2022

Note: This RFC has been updated by RFC 9430

Errata ID: 8231
Status: Reported
Type: Technical
Publication Format(s) : HTML
Reported By: Marco Tiloca
Date Reported: 2025-01-03

Section 3.3.2 says:

The client then needs to indicate during the DTLS handshake which
previously uploaded access token it intends to use. To do so, it MUST
create a COSE_Key structure with the kid that was conveyed in the
rs_cnf claim in the token response from the authorization server and
the key type symmetric.

It should say:

The client then needs to indicate during the DTLS handshake which
previously uploaded access token it intends to use. To do so, it MUST
create a COSE_Key structure with the kid that was conveyed in the
cnf parameter in the token response from the authorization server and
the key type symmetric.

Notes:

The token response includes parameters, not claims.

Also, per Section 3.2 of RFC 9201, the rs_cnf parameter is "OPTIONAL if the token type is "pop" and asymmetric keys are used", while it "MUST NOT be present otherwise." At the same time, the cnf parameter is "REQUIRED if the token type is "pop" and a symmetric key is used."

The quoted paragraph from Section 3.3.2 of RFC 9202 refers to the PSK mode. Hence, per Section 3.2 of RFC 9201, the cnf parameter should be included in the token response from the authorization server (not the rs_cnf parameter).

This is also consistent with the last paragraph in the same Section 3.3.2.

Report New Errata