]> RISE AB

Isafjordsgatan 22 Kista 164 40 Sweden marco.tiloca@ri.se

Ericsson AB

Stockholm 164 80 Sweden john.mattsson@ericsson.com

Security ACE Working Group Internet-Draft This document updates the Datagram Transport Layer Security (DTLS) profile for Authentication and Authorization for Constrained Environments (ACE). In particular, it specifies the use of additional formats of authentication credentials for establishing a DTLS session, when peer authentication is based on asymmetric cryptography. Therefore, this document updates RFC 9202. What is defined in this document is seamlessly applicable also if the profile uses Transport Layer Security (TLS) instead of DTLS, as defined in RFC 9430. Discussion Venues Discussion of this document takes place on the Authentication and Authorization for Constrained Environments Working Group mailing list (ace@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction The Authentication and Authorization for Constrained Environments (ACE) framework defines an architecture to enforce access control for constrained devices. A client (C) requests an evidence of granted permissions from an authorization server (AS) in the form of an access token, then uploads the access token to the target resource server (RS), and finally accesses protected resources at the RS according to what is specified in the access token. The framework has as main building blocks the OAuth 2.0 framework , the Constrained Application Protocol (CoAP) for message transfer, Concise Binary Object Representation (CBOR) for compact encoding, and CBOR Object Signing and Encryption (COSE) for self-contained protection of access tokens. Separate profile documents define in detail how the participants in the ACE architecture communicate, especially as to the security protocols that they use. In particular, the ACE profile defined in specifies how Datagram Transport Layer Security (DTLS) is used to protect communications with transport-layer security in the ACE architecture. The profile has been extended in , in order to allow the alternative use of Transport Layer Security (TLS) when CoAP is transported over TCP or WebSockets . The DTLS profile defined in allows C and the RS to establish a DTLS session with peer authentication based on symmetric or asymmetric cryptography. For the latter case, the profile defines a Raw Public Key (RPK) mode (see ), where authentication relies on the public keys of the two peers as raw public keys . That is, C specifies its public key to the AS when requesting an access token and the AS provides such public key to the target RS as included in the issued access token. When issuing the access token, the AS also provides C with the public key of the RS. Then, C and the RS use their asymmetric keys when performing the DTLS handshake, as defined in . Per , the DTLS profile admits only a COSE_Key object as the format of authentication credentials to use for specifying the public keys of C and the RS as raw public keys. However, it is desirable that additional formats of authentication credentials can be used, such as enhanced raw public keys or public key certificates. This document enables the use of such additional formats in the DTLS profile, by defining how the public keys of C and the RS can be specified by means of CBOR Web Token (CWT) Claims Sets (CCSs) , X.509 certificates , or C509 certificates . This document also enables the DTLS profile to use the CWT Confirmation Method 'ckt' defined in when using a COSE_Key object for specifying a raw public key, thus allowing to identifying the COSE_Key object by reference alternatively to transporting it by value. In particular, this document updates as follows.

• of this document extends the RPK mode defined in , by enabling:
  • The use of CCSs to wrap the raw public keys of C and the RS, i.e., as a new format of authentication credentials that can be used for specifying the public keys of C and the RS as raw public keys (see ).
  • The use of the CWT Confirmation Method 'ckt' to identify a COSE_Key object by reference, when that is the format of authentication credentials used for specifying the public keys of C and the RS as raw public keys (see ).
• of this document defines a new certificate mode, which enables the use of X.509 or C509 certificates to specify the public keys of C and the RS. In either case, certificates can be transported by value or instead identified by reference.

When using the updated RPK mode, the raw public keys of C and the RS do not have to be of the same format. That is, it is possible to have both public keys as a COSE_Key object or as a CCS, or instead one as a COSE_Key object while the other one as a CCS. When both raw public keys are COSE_Keys, it is possible to have both COSE_Keys transported by value, or both identified by reference, or one transported by value while the other one identified by reference. When using the certificate mode, the certificates of C and the RS do not have to be of the same format. That is, it is possible to have both as X.509 certificates, or both as C509 certificates, or one as an X.509 certificate while the other one as a C509 certificate. Furthermore, it is possible to have both certificates transported by value, or both identified by reference, or one transported by value while the other one identified by reference. Also, the RPK mode and the certificate mode can be combined. That is, it is possible that one of the two authentication credentials is a certificate, while the other one is a raw public key. The effective provisioning of an authentication credential identified by reference builds on the assumption that the recipient is storing the authentication credential by value, or is able to retrieve it from a trusted source by means of the reference obtained. If that assumption does not hold, the authentication credential will have to be provided by value. The decision about whether providing authentication credentials by value or by reference depending on the specific situation is left to application policies at C and the AS. Furthermore, C and the AS could explicitly coordinate with each other about exchanging the authentication credentials of C and the RS as transported by value or instead identified by reference, e.g., by relying on the coordination method defined in . When using the formats introduced in this document, authentication credentials are specified by means of the CWT Confirmation Methods "kccs", "x5bag", "x5chain", "x5t", "x5u", "c5b", "c5c", "c5t", and "c5u" that are defined in . What is defined in this document is seamlessly applicable if TLS is used instead of DTLS, as defined in .

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. Readers are expected to be familiar with the terms and concepts described in the ACE framework for Authentication and Authorization and in its DTLS profile , as well as with terms and concepts related to CBOR Web Tokens (CWTs) and CWT Confirmation Methods . The terminology for entities in the considered architecture is defined in OAuth 2.0 . In particular, this includes client (C), resource server (RS), and authorization server (AS). Readers are also expected to be familiar with the terms and concepts related to CoAP , CBOR , Concise Data Definition Language (CDDL) , COSE , DTLS , and the use of raw public keys in DTLS . Note that the term "endpoint" is used here following its OAuth definition , aimed at denoting resources such as /token and /introspect at the AS, and /authz-info at the RS. The CoAP definition, which is "[a]n entity participating in the CoAP protocol" , is not used in this document. This document also refers to the term "authentication credential", which denotes the information associated with an entity, including that entity's public key and parameters associated with the public key. Examples of authentication credentials are CWT Claims Sets (CCSs) , X.509 certificates , and C509 certificates .

Notations Examples throughout this document are expressed in CBOR diagnostic notation as defined in and . Diagnostic notation comments are often used to provide a textual representation of the parameters' keys and values. In the CBOR diagnostic notation used in this document, constructs of the form e'SOME_NAME' are replaced by the value assigned to SOME_NAME in the CDDL model shown in of . For example, {e'x5chain' : h'3081...cb02'} stands for {24 : h'3081...cb02'}. Note to RFC Editor: Please delete the paragraph immediately preceding this note. Also, in the CBOR diagnostic notation used in this document, please replace the constructs of the form e'SOME_NAME' with the value assigned to SOME_NAME in the CDDL model shown in of . Finally, please delete this note.

Updates to the RPK Mode This section updates the RPK mode defined in , as detailed in the following and .

Raw Public Keys as CCSs This section defines how the raw public key of C and the RS can be provided as wrapped by a CCS , instead of as a COSE_Key object . Note that only the differences from are compiled below. If the raw public key of C is wrapped by a CCS, then the following applies.

• The payload of the access token request (see ) is as defined in , with the difference that the "req_cnf" parameter MUST contain a "kccs" structure, with value a CCS specifying the public key of C that has to be bound to the access token. In particular, the CCS MUST include the "cnf" claim specifying the public key of C as a COSE_Key object, SHOULD include the "sub" claim specifying the subject name of C associated with the public key of C, and MAY include additional claims.
• The content of the access token that the AS provides to C in the access token response (see ) is as defined in , with the difference that the "cnf" claim of the access token MUST contain a "kccs" structure, with value a CCS specifying the public key of C that is bound to the access token. In particular, the CCS MUST include the "cnf" claim specifying the public key of C as a COSE_Key object, SHOULD include the "sub" claim specifying the subject name of C associated with the public key of C, and MAY include additional claims.

If the raw public key of the RS is wrapped by a CCS, then the following applies.

• The payload of the access token response is as defined in , with the difference that the "rs_cnf" parameter MUST contain a "kccs" structure, with value a CCS specifying the public key of the RS. In particular, the CCS MUST include the "cnf" claim specifying the public key of the RS as a COSE_Key object, SHOULD include the "sub" claim specifying the subject name of the RS associated with the public key of the RS, and MAY include additional claims.

For the "req_cnf" parameter of the access token request, the "rs_cnf" parameter of the access token response, and the "cnf" claim of the access token, the Confirmation Method "kccs" structure and its identifier are defined in . It is not required that both public keys are wrapped by a CCS. That is, one of the two authentication credentials can be a CCS, while the other one can be a COSE_Key object transported by value as per or identified by reference as per of this document.

Examples shows an example of access token request from C to the AS.

Access Token Request Example for RPK Mode, with the Public Key of C Wrapped by a CCS Conveyed within "req_cnf"

shows an example of access token response from the AS to C.

Access Token Response Example for RPK Mode, with the Public Key of the RS Wrapped by a CCS, Conveyed within "rs_cnf"

Raw Public Keys as COSE_Keys Identified by Reference As per , COSE_Key objects used for specifying raw public keys are transported by value in the access token request and response messages, as well as within access tokens. This section extends the DTLS profile by allowing to identifying those COSE_Key objects by reference, alternatively to transporting those by value. Note that only the differences from are compiled below. The following relies on the CWT Confirmation Method 'ckt' defined in . When using a 'ckt' structure, this conveys the thumbprint of a COSE_Key object computed as per . In particular, the hash function used MUST be SHA-256 , which is mandatory to support when supporting COSE Key thumbprints. If the raw public key of C is specified as a COSE_Key object COSE_KEY_C and the intent is to identify it by reference, then the following applies.

• The payload of the access token request (see ) is as defined in , with the difference that the "req_cnf" parameter MUST contain a "ckt" structure, with value the thumbprint of COSE_KEY_C.
• The content of the access token that the AS provides to C in the access token response (see ) is as defined in , with the difference that the "cnf" claim of the access token MUST contain a "ckt" structure, with value the thumbprint of COSE_KEY_C.

If the raw public key of the RS is specified as a COSE_Key object COSE_KEY_RS and the intent is to identify it by reference, then the following applies.

• The payload of the access token response is as defined in , with the difference that the "rs_cnf" parameter MUST contain a "ckt" structure, with value the thumbprint of COSE_KEY_RS.

When both public keys are specified as COSE_Key objects, it is possible to have both transported by value, or both identified by reference, or one transported by value while the other one identified by reference. Note that the use of COSE Key thumbprints per is applicable only to authentication credentials that are COSE_Key objects. That is, the 'ckt' structure MUST NOT be used to identify authentication credentials of other formats and that include a COSE_Key object as part of their content, such as CCSs as defined in of this document.

Examples shows an example of access token request from C to the AS.

Access Token Request Example for RPK Mode, with the Public Key of C Specified as a COSE_Key Object Identified by Reference within "req_cnf"

shows an example of access token response from the AS to C.

Access Token Response Example for RPK Mode, with the Public Key of the RS Specified as a COSE_Key Object Identified by Reference within "rs_cnf"

Certificate Mode This section defines a new certificate mode of the DTLS profile, which enables the use of public key certificates to specify the public keys of C and the RS. Compared to the RPK mode defined in and extended in of this document, the certificate mode displays the differences compiled below. The authentication credential of C and/or of the RS is a public key certificate, i.e., an X.509 certificate or a C509 certificate .

• The CWT Confirmation Methods "x5chain", "x5bag", "c5c", and "c5b" defined in are used to transport such authentication credentials by value.
• The CWT Confirmation Methods "x5t", "x5u", "c5t", and "c5u" defined in are used to identify such authentication credentials by reference.

If the authentication credential AUTH_CRED_C of C is a public key certificate, then the following applies.

• The "req_cnf" parameter of the access token request (see ) specifies AUTH_CRED_C as follows. If AUTH_CRED_C is an X.509 certificate, the "req_cnf" parameter MUST contain:
  • An "x5chain" or "x5bag" structure, if AUTH_CRED_C is transported by value within a certificate chain or a certificate bag, respectively; or
  • An "x5t" or "x5u" structure, if AUTH_CRED_C is identified by reference through a hash value (a thumbprint) or a URI , respectively.
  If AUTH_CRED_C is a C509 certificate, the "req_cnf" parameter MUST contain:
  • A "c5c" or "c5b" structure, if AUTH_CRED_C is transported by value within a certificate chain or a certificate bag, respectively; or
  • A "c5t" or "c5u" structure, if AUTH_CRED_C is identified by reference through a hash value (a thumbprint) or a URI , respectively.
• The "cnf" claim of the access token that the AS provides to C in the access token response (see ) specifies AUTH_CRED_C as follows. If AUTH_CRED_C is an X.509 certificate, the "cnf" claim MUST contain:
  • An "x5chain" or "x5bag" structure, if AUTH_CRED_C is transported by value within a certificate chain or a certificate bag, respectively; or
  • An "x5t" or "x5u" structure, if AUTH_CRED_C is identified by reference through a hash value (a thumbprint) or a URI , respectively.
  If AUTH_CRED_C is a C509 certificate, the "cnf" claim MUST contain:
  • A "c5c" or "c5b" structure, if AUTH_CRED_C is transported by value within a certificate chain or a certificate bag, respectively; or
  • A "c5t" or "c5u" structure, if AUTH_CRED_C is identified by reference through a hash value (a thumbprint) or a URI , respectively.

If the authentication credential AUTH_CRED_RS of the RS is a public key certificate, then the following applies.

• The "rs_cnf" parameter of the access token response specifies AUTH_CRED_RS as follows. If AUTH_CRED_RS is an X.509 certificate, the "rs_cnf" parameter MUST contain:
  • An "x5chain" or "x5bag" structure, if AUTH_CRED_RS is transported by value within a certificate chain or a certificate bag, respectively; or
  • An "x5t" or "x5u" structure, if AUTH_CRED_RS is identified by reference through a hash value (a thumbprint) or a URI , respectively.
  If AUTH_CRED_RS is a C509 certificate, the "rs_cnf" parameter MUST contain:
  • A "c5c" or "c5b" structure, if AUTH_CRED_RS is transported by value within a certificate chain or a certificate bag, respectively; or
  • A "c5t" or "c5u" structure, if AUTH_CRED_RS is identified by reference through a hash value (a thumbprint) or a URI , respectively.

For the "req_cnf" parameter of the access token request, the "rs_cnf" parameter of the access token response, and the "cnf" claim of the access token, the structures "x5bag", "x5chain", "x5t", "x5u", "c5b", "c5c", "c5t", and "c5u" are defined in , together with their identifiers. When using either of the structures, the specified authentication credential is just the end-entity certificate. As per and , a public key certificate is specified in the Certificate message of the DTLS handshake. For X.509 certificates, the TLS Certificate Type is "X509", as defined in . For C509 certificates, the TLS certificate type is "C509 Certificate", as defined in . It is not required that AUTH_CRED_C and AUTH_CRED_RS are both X.509 certificates or both C509 certificates. Also, it is not required that AUTH_CRED_C and AUTH_CRED_RS are both transported by value or both identified by reference. Finally, one of the two authentication credentials can be a public key certificate, while the other one can be a raw public key. This is consistent with the admitted, combined use of raw public keys and certificates, as discussed in .

Examples shows an example of access token request from C to the AS. In the example, C specifies its authentication credential by means of an "x5chain" structure, transporting by value only its X.509 certificate.

Access Token Request Example for Certificate Mode with an X.509 Certificate as Authentication Credential of C, Transported by Value within "req_cnf"

shows an example of access token response from the AS to C. In the example, the AS specifies the authentication credential of the RS by means of an "x5chain" structure, transporting by value only the X.509 certificate of the RS.

Access Token Response Example for Certificate Mode with an X.509 Certificate as Authentication Credential of the RS, Transported by Value within "rs_cnf"

The following shows a variation of the two previous examples, where X.509 certificates used as authentication credentials are instead identified by reference. shows an example of access token request from C to the AS. In the example, C specifies its authentication credential by means of an "x5t" structure, identifying by reference its X.509 certificate.

Access Token Request Example for Certificate Mode with an X.509 Certificate as Authentication Credential of C, Identified by Reference within "req_cnf"

shows an example of access token response from the AS to C. In the example, the AS specifies the authentication credential of the RS by means of an "x5t" structure, identifying by reference the X.509 certificate of the RS.

Access Token Response Example for Certificate Mode with an X.509 Certificate as Authentication Credential of the RS, Identified by Reference within "rs_cnf"

Security Considerations The security considerations from and apply to this document as well. Furthermore:

• When using the CWT Confirmation Method 'ckt' for identifying by reference a COSE_Key object that is used for specifying a raw public key, the security considerations from apply.
• When using public key certificates as authentication credentials, the security considerations from apply.
• When using X.509 certificates as authentication credentials, the security considerations from , , , , , and apply.
• When using C509 certificates as authentication credentials, the security considerations from apply.

Consistent with the ACE architecture, C and the RS securely obtain each others' authentication credential from the AS acting as trusted third party, i.e., through the access token response sent to C and through the issued access token uploaded to the RS, respectively. Nevertheless, C and the RS are responsible for verifying the integrity and validity of obtained authentication credentials when those are CCSs or public key certificates as defined in this document. For public key certificates, verifying their validity may require using a Real-Time Clock (RTC). Trusted certification authorities (CAs) should be selected very carefully and certificate revocation should be supported. The revocation mechanism specifically used depends on the application. For example Certificate Revocation Lists or the Online Certificate Status Protocol (OCSP) may be used when authentication credentials are X.509 certificates. Similarly for CCSs, verifying their validity and handling their revocation require C and the RS to very carefully select relevant trust anchors and to have a well-defined trust-establishment process. Note that self-signed certificates or CCSs provided to C and the RS cannot result in modifying the set of trust anchors. A common way for a new trust anchor to be added to (or removed from) a device is by performing a firmware upgrade. A longer discussion on trust and validation in constrained devices is provided by .

IANA Considerations This document has no actions for IANA.

References Normative References Ericsson AB Ericsson AB University of Glasgow RISE AB IN Groupe NIO This document specifies a CBOR encoding of X.509 certificates. The resulting certificates are called C509 certificates. The CBOR encoding supports a large subset of RFC 5280 and common certificate profiles, and it is extensible. Two types of C509 certificates are defined. One type is an invertible CBOR re-encoding of DER-encoded X.509 certificates with the signature field copied from the DER encoding. The other type is identical except that the signature is computed over the CBOR encoding instead of the DER encoding, thereby avoiding the use of ASN.1. Both types of certificates have the same semantics as X.509 while providing comparable size reduction. This document also specifies CBOR-encoded data structures for certification requests and certification request templates, new COSE headers, as well as a TLS certificate type and a file format for C509. This document updates RFC 6698 by extending the TLSA selectors registry to include C509 certificates. Ericsson Ericsson RISE RISE This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework. It utilizes Ephemeral Diffie-Hellman Over COSE (EDHOC) for achieving mutual authentication between an ACE-OAuth client and resource server, and it binds an authentication credential of the client to an ACE-OAuth access token. EDHOC also establishes an Object Security for Constrained RESTful Environments (OSCORE) Security Context, which is used to secure communications between the client and resource server when accessing protected resources according to the authorization information indicated in the access token. This profile can be used to delegate management of authorization information from a resource-constrained server to a trusted host with less severe limitations regarding processing power and memory. A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] This document specifies version 1.2 of the Datagram Transport Layer Security (DTLS) protocol. The DTLS protocol provides communications privacy for datagram protocols. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document updates DTLS 1.0 to work with TLS version 1.2. [STANDARDS-TRACK] The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK] This document updates RFC 5280, the "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile". This document changes the set of acceptable encoding methods for the explicitText field of the user notice policy qualifier and clarifies the rules for converting internationalized domain name labels to ASCII. This document also provides some clarifications on the use of self-signed certificates, trust anchors, and some updated security considerations. [STANDARDS-TRACK] This document specifies a new certificate type and two TLS extensions for exchanging raw public keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). The new certificate type allows raw public keys to be used for authentication. The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation. CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments. The Constrained Application Protocol (CoAP), although inspired by HTTP, was designed to use UDP instead of TCP. The message layer of CoAP over UDP includes support for reliable delivery, simple congestion control, and flow control. Some environments benefit from the availability of CoAP carried over reliable transports such as TCP or Transport Layer Security (TLS). This document outlines the changes required to use CoAP over TCP, TLS, and WebSockets transports. It also formally updates RFC 7641 for use with these transports and RFC 7959 to enable the use of larger messages over a reliable transport. CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR), and CBOR Object Signing and Encryption (COSE) is used for added application-layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value. CWT is derived from JSON Web Token (JWT) but uses CBOR rather than JSON. The updates to RFC 5280 described in this document provide alignment with the 2008 specification for Internationalized Domain Names (IDNs) and includes support for internationalized email addresses in X.509 certificates. The updates ensure that name constraints for email addresses that contain only ASCII characters and internationalized email addresses are handled in the same manner. This document obsoletes RFC 8399. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. This specification describes how to declare in a CBOR Web Token (CWT) (which is defined by RFC 8392) that the presenter of the CWT possesses a particular proof-of-possession key. Being able to prove possession of a key is also sometimes described as being the holder-of-key. This specification provides equivalent functionality to "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)" (RFC 7800) but using Concise Binary Object Representation (CBOR) and CWTs rather than JavaScript Object Notation (JSON) and JSON Web Tokens (JWTs). The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines a set of algorithms that can be used with the CBOR Object Signing and Encryption (COSE) protocol (RFC 9052). This document, along with RFC 9052, obsoletes RFC 8152. This document specifies version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. The DTLS 1.3 protocol is based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees with the exception of order protection / non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document obsoletes RFC 6347. This specification defines a framework for authentication and authorization in Internet of Things (IoT) environments called ACE-OAuth. The framework is based on a set of building blocks including OAuth 2.0 and the Constrained Application Protocol (CoAP), thus transforming a well-known and widely used authorization solution into a form suitable for IoT devices. Existing specifications are used where possible, but extensions are added and profiles are defined to better serve the IoT use cases. This specification defines new parameters and encodings for the OAuth 2.0 token and introspection endpoints when used with the framework for Authentication and Authorization for Constrained Environments (ACE). These are used to express the proof-of-possession (PoP) key the client wishes to use, the PoP key that the authorization server has selected, and the PoP key the resource server uses to authenticate to the client. This specification defines a profile of the Authentication and Authorization for Constrained Environments (ACE) framework that allows constrained servers to delegate client authentication and authorization. The protocol relies on DTLS version 1.2 or later for communication security between entities in a constrained network using either raw public keys or pre-shared keys. A resource-constrained server can use this protocol to delegate management of authorization information to a trusted host with less-severe limitations regarding processing power and memory. This document updates "Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE)" (RFC 9202) by specifying that the profile applies to TLS as well as DTLS. This document defines a new name form for inclusion in the otherName field of an X.509 Subject Alternative Name and Issuer Alternative Name extension that allows a certificate subject to be associated with an internationalized email address. This document updates RFC 5280 and obsoletes RFC 8398. X.509v3 public key certificates are profiled in RFC 5280. Short-lived certificates are seeing greater use in the Internet. The Certification Authority (CA) that issues these short-lived certificates do not publish revocation information because the certificate lifespan that is shorter than the time needed to detect, report, and distribute revocation information. Some long-lived X.509v3 public key certificates never expire, and they are never revoked. This specification defines the noRevAvail certificate extension so that a relying party can readily determine that the CA does not publish revocation information for the certificate, and it updates the certification path validation algorithm defined in RFC 5280 so that revocation checking is skipped when the noRevAvail certificate extension is present. This document updates RFC 5280 to replace the algorithm for X.509 policy validation with an equivalent, more efficient algorithm. The original algorithm built a structure that scaled exponentially in the worst case, leaving implementations vulnerable to denial-of-service attacks. This specification defines a method for computing a hash value over a CBOR Object Signing and Encryption (COSE) Key. It specifies which fields within the COSE Key structure are included in the cryptographic hash computation, the process for creating a canonical representation of these fields, and how to hash the resulting byte sequence. The resulting hash value, referred to as a "thumbprint", can be used to identify or select the corresponding key. NIST In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This memo defines Transport Layer Security (TLS) extensions and associated semantics that allow clients and servers to negotiate the use of OpenPGP certificates for a TLS session, and specifies how to transport OpenPGP certificates via TLS. It also defines the registry for non-X.509 certificate types. This document is not an Internet Standards Track specification; it is published for informational purposes. This document specifies a protocol useful in determining the current status of a digital certificate without requiring Certificate Revocation Lists (CRLs). Additional mechanisms addressing PKIX operational requirements are specified in separate documents. This document obsoletes RFCs 2560 and 6277. It also updates RFC 5912. The CBOR Object Signing and Encryption (COSE) message structure uses references to keys in general. For some algorithms, additional properties are defined that carry parameters relating to keys as needed. The COSE Key structure is used for transporting keys outside of COSE messages. This document extends the way that keys can be identified and transported by providing attributes that refer to or contain X.509 certificates. RISE AB Ericsson AB This document updates the Authentication and Authorization for Constrained Environments framework (ACE, RFC 9200) as follows. (1) It defines the Short Distribution Chain (SDC) workflow that the authorization server (AS) can use for uploading an access token to a resource server on behalf of the client. (2) For the OAuth 2.0 token endpoint, it defines new parameters and encodings and it extends the semantics of the "ace_profile" parameter. (3) For the OAuth 2.0 authz-info endpoint, it defines a new parameter and its encoding. (4) It defines how the client and the AS can coordinate on the exchange of the client's and resource server's public authentication credentials, when those can be transported by value or identified by reference; this extends the semantics of the "rs_cnf" parameter for the OAuth 2.0 token endpoint, thus updating RFC 9201. (5) It extends the error handling at the AS, for which it defines a new error code. (6) It deprecates the original payload format of error responses conveying an error code, when CBOR is used to encode message payloads. For those responses, it defines a new payload format aligned with RFC 9290, thus updating in this respect also the profiles defined in RFC 9202, RFC 9203, and RFC 9431. (7) It amends two of the requirements on profiles of the framework.

Examples with Hybrid Settings This section provides additional examples where, within the same ACE execution workflow, C and the RS use different formats of raw public keys (see ), or different formats of certificates (see ), or a combination of the RPK mode and certificate mode (see ).

RPK Mode (Raw Public Keys of Different Formats) shows an example of access token request from C to the AS, where the public key of C is conveyed as a COSE Key.

Access Token Request Example for RPK Mode, with the Public Key of C Conveyed as a COSE Key within "req_cnf"

shows an example of access token response from the AS to C, where the public key of the RS is wrapped by a CCS.

Access Token Response Example for RPK Mode, with the Public Key of the RS Wrapped by a CCS within "rs_cnf"

Certificate Mode (Certificates of Different Formats) shows an example of access token request from C to the AS. In the example, C specifies its authentication credential by means of an "x5chain" structure, transporting by value only its X.509 certificate.

Access Token Request Example for Certificate Mode with an X.509 Certificate as Authentication Credential of C, Transported by Value within "req_cnf"

shows an example of access token response from the AS to C. In the example, the AS specifies the authentication credential of the RS by means of a "c5c" structure, transporting by value only the C509 certificate of the RS.

Access Token Response Example for Certificate Mode with a C509 Certificate as Authentication Credential of the RS, Transported by Value within "rs_cnf"

The following shows a variation of the two previous examples, where certificates used as authentication credentials are instead identified by reference. shows an example of access token request from C to the AS. In the example, C specifies its authentication credential by means of an "x5t" structure, identifying by reference its X.509 certificate.

Access Token Request Example for Certificate Mode with an X.509 Certificate as Authentication Credential of C, Identified by Reference within "req_cnf"

shows an example of access token response from the AS to C. In the example, the AS specifies the authentication credential of the RS by means of a "c5t" structure, identifying by reference the C509 certificate of the RS.

Access Token Response Example for Certificate Mode with a C509 Certificate as Authentication Credential of the RS, Identified by Reference within "rs_cnf"

Combination of RPK Mode and Certificate Mode shows an example of access token request from C to the AS, where the public key of C is wrapped by a CCS.

Access Token Request Example for RPK Mode, with the Public Key of C Wrapped by a CCS within "req_cnf"

shows an example of access token response from the AS to C. In the example, the AS specifies the authentication credential of the RS by means of an "x5chain" structure, transporting by value only the X.509 certificate of the RS.

Access Token Response Example for Certificate Mode with an X.509 Certificate as Authentication Credential of the RS, Transported by Value within "rs_cnf"

The following shows a variation of the two previous examples, where one authentication credential is a raw public key specified by a COSE_Key Object and the other authentication credential is an X.509 certificate, with both credentials identified by reference. shows an example of access token request from C to the AS. In the example, C specifies its authentication credential by means of a "ckt" structure, identifying by reference the COSE_Key Object that specifies its public key.

Access Token Request Example for RPK Mode, with the Public Key of C Specified as a COSE_Key Object Identified by Reference within "req_cnf"

shows an example of access token response from the AS to C. In the example, the AS specifies the authentication credential of the RS by means of an "x5t" structure, identifying by reference the X.509 certificate of the RS.

Access Token Response Example for Certificate Mode with an X.509 Certificate as Authentication Credential of the RS, Identified by Reference within "rs_cnf"

CDDL Model

CDDL Model

Document Updates

Version -03 to -04

• Editorial fixes and improvements.

Version -02 to -03

• Editorial fixes and improvements.

Version -01 to -02

• Considerations on providing credentials by value or by reference.
• Minor fixes in examples.
• Added more examples with hybrid settings.
• Extended security considerations.
• Updated CBOR abbreviations for a more efficient use of codepoints.
• Updated references.
• Editorial improvements.

Version -00 to -01

• Enabled use of COSE Keys identified by reference with a thumbprint.
• Changed CBOR abbreviations to not collide with existing codepoints.
• Fixes in the examples in CBOR diagnostic notation.
• Updated references.
• Editorial improvements.

Acknowledgments The authors sincerely thank and for their comments and feedback. This work was supported by the Sweden's Innovation Agency VINNOVA within the EUREKA CELTIC-NEXT project CYPRESS; and by the H2020 project SIFIS-Home (Grant agreement 952652).