]> University of Applied Sciences Bonn-Rhein-Sieg

Germany Hannes.Tschofenig@gmx.net

Arm Limited

brendan.moran.ietf@gmail.com

Fraunhofer SIT

Rheinstrasse 75 Darmstadt 64295 Germany henk.birkholz@sit.fraunhofer.de

Security COSE Internet-Draft The CBOR Object Signing and Encryption (COSE) message structure uses references to keys and defines header parameters to carry chains of X.509 certificates. This specification extends this functionality to CBOR Web Tokens (CWTs).

Introduction The CBOR Object Signing and Encryption (COSE) message structure uses references to keys and defines header parameters to carry chains of X.509 certificates. The header parameters for conveying X.509 certificate chains in a COSE payload are defined in . This document is inspired by RFC 9360 and defines header parameters to convey chains of CBOR Web Tokens (CWTs) . The use of chains of CWTs allows a trust infrastructure established by CWTs to be used with COSE. The Concise Binary Object Representation (CBOR) key structures that have been defined in COSE support the use of X.509 certificates. This specification applies the well-proven concepts to CWTs. These chains of CWTs allow path validation similarly to what a X.509 certificate-based Public Key Infrastructure (PKI) provides. Since does not define the semantics of path validation for CWTs, new terminology is introduced. This document is structured as follows: After introducing some terms, we describe path validation for CWTs. Then, we define new header parameters.

Terminology and Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 . The following terms are useful for readers of this document: End Entity: user of CWT and/or end user system that is the subject of a CWT; CA: certification authority; RFC 8747 calls this entity the "issuer" and describes it as "the party that creates the CWT and binds the claims about the subject to the proof-of-possession key". In an OAuth-based system, this entity often corresponds to an authorization server. CA CWT: A CWT that is self-issued whereby the same name appears in the subject and issuer claims. RA: registration authority, i.e., an optional system to which a CA delegates certain management functions; while often used in PKI deployments it is a role that has not found usage in systems using CWTs. CRL issuer: a system that generates and signs Certificate Revocation Lists (CRLs); The term CRL is used generically to also refer to status lists . repository: a system or collection of distributed systems that stores CWTs and CRLs and serves as a means of distributing these CWTs and CRLs to end entities. These repositories may be append-only databases, in the style of . Trust Anchor: As defined in and , a Trust Anchor "represents an authoritative entity via a public key and associated data. The public key is used to verify digital signatures, and the associated data is used to constrain the types of information for which the trust anchor is authoritative." The trust anchor may be a CWT, a raw public key, or other structure, as appropriate. Subject Public Key (Info): The "confirmation" claim, defined in , used to carry the public key and the algorithm with which the key is used.

CWT Path Validation The goal of path validation is to verify the binding between a subject name and the public key, as represented in the target CWT, based on the public key of the trust anchor. In most cases, the target CWT will be an end entity CWT. Verifying the binding between the name and subject public key requires obtaining a sequence of certificates that support that binding. For path validation to work CWTs that have a minimum number of claims, namely: Subject Issuer Confirmation Valid paths begin with CWTs issued by a trust anchor and the trust anchor is an input to the algorithm. The algorithm in Section 6 of requires the public key of the CA, the CA's name, and any constraints upon the set of paths that may be validated using this key. The path validation algorithm verifies that a prospective certification path (a sequence of n CWTs) satisfies the following conditions: (a) for all x in {1, ..., n-1}, the subject of CWT x is the issuer of CWT x+1; (b) CWT 1 is issued by the trust anchor; (c) CWT n is the CWT to be validated (i.e., the target CWT); and Note: When the trust anchor is provided in the form of a self-signed CWT, this self-signed CWT is not included as part of the prospective certification path. As a variation to the algorithm presented in Section 6 of , there is no strict requirement for a CWT being valid in terms of its lifetime (as indicated by the "Expiration Time" and the "Not Before" claims) since CWTs may not necessarily carry these claims and validity may be determined via different means, which are outside the scope of this algorithm. Path validation is an important part of establishing trust in a CWT and when applying path validation, as defined in Section 6 of , to CWTs the reader needs to treat them as certificates. It is important to keep in mind that many of the advanced features available with an X.509 certificate-based PKI are, at the time of writing, not available with CWTs. The authors do, however, believe that differences will decrease over time as CWT-based deployments scale.

CWT COSE Header Parameters Parties that intend to rely on the assertions made by a CWTs obtained from any of these methods still need to validate it. This validation can be done according to the PKIX rules specified in or by using a different trust structure, such as a trusted distributor for self-signed CWTs. The PKIX validation includes matching against the trust anchors configured for the application. These rules apply when the validation succeeds in a single step as well as when CWT chains need to be built. If the application cannot establish trust in the CWT, the public key contained in the CWT cannot be used for cryptographic operations. The header parameters defined in this document are as follows: cwt-bag: This header parameter contains a bag of CWTs, which is unordered and may contain self-signed CWTs. Note that there could be duplicate CWTs. The CWT bag can contain CWTs that are completely extraneous to the message. (An example of this would be where a signed message is being used to transport a CWT containing a key agreement key.) As the CWT bag is unordered, the party evaluating the signature will need to be capable of building the CWT path as necessary. That party will also have to take into account that the bag may not contain the full set of CWTs needed to build any particular chain.

cwt-chain: This header parameter contains an ordered array of CWTs. The CWTs are to be ordered starting with the CWT containing the end entity key followed by the CWT that signed it, and so on. There is no requirement for the entire chain to be present in the element if there is reason to believe that the relying party already has, or can locate, the missing CWT. This means that the relying party is still required to do path building but that a candidate path is proposed in this header parameter.

cwt-t: This header parameter identifies the end entity CWT by a hash value (a thumbprint). The 'cwt-t' header parameter is represented as an array of two elements. The first element is an algorithm identifier that is an integer or a string containing the hash algorithm identifier corresponding to the Value column (integer or text string) of the algorithm registered in the "COSE Algorithms" registry (see ). The second element is a binary string containing the hash value computed over the CWT.

cwt-u: This header parameter provides the ability to identify a CWT by a URI . It contains a CBOR text string. The referenced resource can be any of the following media types:

The header parameters are used in the following locations: COSE_Signature and COSE_Sign1 objects: In these objects, the parameters identify the CWT to be used for validating the signature. COSE_recipient objects: In this location, the parameters identify the CWT for the recipient of the message. The labels assigned to each header parameter can be found in .

Below is an equivalent Concise Data Definition Language (CDDL) description (see ) of the text above.

The contents of "bstr" are the bytes of a CWT.

CWTs and Static-Static ECDH The header parameters defined in the previous section are used to identify the recipient CWT. In this section, we define the algorithm-specific parameters that are used for identifying or transporting the sender's key for static-static key agreement algorithms. These attributes are defined analogously to those in the previous section. There is no definition for the CWT bag, as the same parameter would be used for both the sender and recipient. cwt-chain-sender: This header parameter contains the chain of CWT starting with the sender's key exchange CWT. The structure is the same as 'cwt-chain'. cwt-t-sender: This header parameter contains the hash value for the sender's key exchange CWT. The structure is the same as 'cwt-t'. cwt-u-sender: This header parameter contains a URI for the sender's key exchange CWT. The structure and processing are the same as 'cwt-u'.

Example TBD

Security Considerations Establishing trust in a CWT is a vital part of processing. A major component of establishing trust is determining what the set of trust anchors are for the process. A new self-signed CWT appearing on the client cannot be a trigger to modify the set of trust anchors, because a well-defined trust-establishment process is required. One common way for a new trust anchor to be added to (or removed from) a device is by doing a new firmware upgrade. In constrained systems, there is a trade-off between the order of checking the signature and checking the CWT for validity. Validating CWTs may require that network resources be accessed in order to get status information or retrieve CWTs during path building. The resulting network access can consume power and network bandwidth. On the other hand, if the CWT are validated after the signature is validated, an oracle can potentially be built based on detecting the network resources, which is only done if the signature validation passes. In any event, both the signature validation and the CWT validation MUST be completed successfully before acting on any requests. The end entity CWT MUST be integrity protected by COSE. Without proof of possession, an attacker can trick the CA into issuing an identity-misbinding CWT with someone else's "borrowed" public key but with a different subject. An on-path attacker can then perform an identity-misbinding attack by replacing the real end entity CWT in COSE with such an identity- misbinding CWT. end entity CWTs contain identities that a passive on-path attacker eavesdropping on the conversation can use to identify and track the subject. The 'cwt-t' and 'cwt-u' header parameters are just alternative permanent identifiers and can also be used to track the subject. To provide identity protection, COSE can be sent inside another security protocol providing confidentiality. Additionally, the encryption capabilities of COSE itself can be used to protect the CWT content. When processing the 'cwt-u' header parameter, the security considerations of , and specifically those defined in Section 7.1 of , also apply. Protecting the integrity of the 'cwt-bag', 'cwt-chain', and 'cwt-t' contents by placing them in the protected header bucket can help mitigate some risks of a misbehaving CA (cf. Section 5.1 of ). The security of the algorithm used for 'cwt-t' does not affect the security of the system, as this header parameter selects which CWT that is already present on the system should be used, but it does not provide any trust.

IANA Considerations

COSE Header Parameters Registry IANA has registered the new COSE Header parameters in in the "COSE Header Parameters" registry. The "Value Registry" field is empty for all of the items. For each item, the "Reference" field points to this document.

COSE Header Algorithm Parameters Registry IANA has registered the new COSE Header Algorithm parameters in in the "COSE Header Algorithm Parameters" registry. For each item, the "Reference" field points to this document.

Media Type application/cwt When the application/cwt media type is used, the data is a CBOR sequence of single-entry COSE_CWT structures (encoding "bstr"). If the parameter "usage" is set to "chain", this sequence indicates a CWT chain. The application/cwt media type is already registered by and this document updates the IANA entry of this media type : Type name: application Subtype name: cwt Required parameters: N/A Optional parameters: usage Can be absent to provide no further information about the intended meaning of the order in the CBOR sequence of CWT. Can be set to "chain" to indicate that the sequence of data items is to be interpreted as a CWT chain. Encoding considerations: binary Security considerations: See the Security Considerations section of RFC 8392 and [TBD: This RFC]. Interoperability considerations: N/A Published specification: RFC 8392 and [TBD: This RFC] Applications that use this media type: Applications that employ COSE and use CWTs, including IoT applications and digital credentials in general. Fragment identifier considerations: N/A Additional information: Deprecated alias names for this type: N/A Magic number(s): N/A File extension(s): N/A Macintosh file type code(s): N/A Person & email address to contact for further information: iesg@ietf.org Intended usage: COMMON Restrictions on usage: N/A Author: COSE WG Change controller: IESG Provisional registration? No

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. This document describes four optional security service extensions for S/MIME. [STANDARDS-TRACK] 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 defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. This memo documents an Internet Best Current Practice. 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. 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. A trust anchor represents an authoritative entity via a public key and associated data. The public key is used to verify digital signatures, and the associated data is used to constrain the types of information for which the trust anchor is authoritative. A relying party uses trust anchors to determine if a digitally signed object is valid by verifying a digital signature using the trust anchor's public key, and by enforcing the constraints expressed in the associated data for the trust anchor. This document describes some of the problems associated with the lack of a standard trust anchor management mechanism and defines requirements for data formats and push-based protocols designed to address these problems. This document is not an Internet Standards Track specification; it is published for informational purposes. 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 defines Object Security for Constrained RESTful Environments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE). OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols. Although an optional functionality of CoAP, OSCORE alters CoAP options processing and IANA registration. Therefore, this document updates RFC 7252. Vulnerabilities in Internet of Things (IoT) devices have raised the need for a reliable and secure firmware update mechanism suitable for devices with resource constraints. Incorporating such an update mechanism is a fundamental requirement for fixing vulnerabilities, but it also enables other important capabilities such as updating configuration settings and adding new functionality. In addition to the definition of terminology and an architecture, this document provides the motivation for the standardization of a manifest format as a transport-agnostic means for describing and protecting firmware updates. 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. 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. 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. MATTR Bundesdruckerei SPRIND This specification defines a mechanism called Token Status List (abbreviated TSL), data structures and processing rules for representing the status of tokens secured by JSON Object Signing and Encryption (JOSE) or CBOR Object Signing and Encryption (COSE), such as JWT, SD-JWT VC, CBOR Web Token and ISO mdoc. It also defines an extension point and a registry for future status mechanisms. This document defines the terminology and interaction patterns involved in the deployment of Key Transparency in a general secure group messaging infrastructure, and specifies the security properties that the protocol provides. It also gives more general, non- prescriptive guidance on how to securely apply Key Transparency to a number of common applications. IANA

Contributor We would like to thank Ken Takayama for his work on the IETF SUIT trust domains draft, which created the idea for writing this specification. Ken provided valuable review feedback.

Acknowledgments Add your name here.