]> IMT Atlantique

dmytro.ochkas@imt-atlantique.fr

IMT Atlantique

helene.le-bouder@imt-atlantique.fr

IMT Atlantique

alexander.pelov@imt-atlantique.fr

General Internet-Draft This document describes JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) serializations with Ascon which received a lot of attention in the area of lightweight cryptography. In 2019, as a part of CAESAR competition, Ascon-128 and Ascon-128a were selected as the first choice for the lightweight authenticated encryption . After, in 2023, National Institute of Standards and Technology (NIST) selected Ascon family of cryptographic algorithms to be the standard for lightweight cryptography . This recognition makes it particularly interesting to use Ascon with COSE and JOSE structures. This document does not define any new cryptography, only serializations of existing cryptographic systems described in .

Introduction Constrained networks such as Internet of Things (IoT) networks most of the time are characterized by the limited computational power and autonomy. In this context, the choice of suitable cryptographic algorithms that provide robust security without consuming large amount of resources is essential. As a winner of the lightweight cryptography standardization process conducted by NIST, Ascon family of cryptographic algorithms is a perfect candidate for the described situation. Ascon-Based Lightweight Cryptography Standards for Constrained Devices introduces a suite of algorithms to provide Authenticated Encryption with Associated Data (AEAD), a hash function, and two eXtendable Output Functions (XOFs). This document focuses on the AEAD part of Ascon standard. It enables the usage of Ascon-AEAD128 with JOSE and COSE for content encryption.

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.

Ascon algorithms In the scope of this document, only the authenticated encryption Ascon is allowed for. Ascon's encryption and decryption algorithms are parametrized by the key length k, the rate r, and the internal round numbers a and b. specifies the Ascon-AEAD128 algorithm with the following parameters: Key Length, k Rate, r Outer permutation rounds, a Inner permutation rounds, b 128 128 12 8 COSE encryption and decryption with Ascon-AEAD128 is done in accordance with Section 5.3 of . Thus, this document requests the registration of the Ascon-AEAD128 algorithm in : Name alg Description Ascon-AEAD128 TBD (requested assignment 35) CBOR Object Encryption Algorithm for Ascon-AEAD128 In COSE, keys may be obtained from either a key structure or a recipient structure . When using a COSE key for this algorithm, the following checks are made: The "kty" field MUST be present, and it MUST be "Symmetric". If the "alg" field is present, it MUST match the Ascon-AEAD128 algorithm being used. If the "key_ops" field is present, it MUST include "encrypt" when encrypting. If the "key_ops" field is present, it MUST include "decrypt" when decrypting. Also, this document requests the registration of the Ascon-AEAD128 algorithm in : Name enc Description Ascon-AEAD128 Ascon-AEAD128 JSON Object Encryption Algorithm for Ascon-AEAD128 Implementations that are encrypting or decrypting MUST validate that the key type, key length, and algorithm are correct and appropriate for the entities involved.

IV Header Parameter Unlike some common AEAD algorithms, Ascon distinguishes between the notion of initialization vector (IV) and nonce (N). While N is the input argument for the Ascon encryption/decryption functions, IV is the constant defined for each Ascon algorithm and is based on its parameters. However, does not define a separate header parameter to specify Nonce. Thus, in COSE, whenever Full Initialization Vector Header Parameter (Name: IV, Label: 5) or Partial Initialization Vector Header Parameter (Name: Partial IV, Label: 6) is specified it MUST refer to the N argument of the corresponding Ascon function. On the other hand, JSON Web Signature and Encryption Header Parameters registry at defines both Nonce Header Parameter ("nonce") and Initialization Vector Header Parameter ("iv"). However, the "nonce" parameter is intended to be used only for signatures. That is, in JOSE, "iv" parameters MUST refer to the N argument of the corresponding Ascon function. There SHOULD NOT be "nonce" parameters specified while using Ascon for content encryption. In case "nonce" parameter is specified it MUST be ignored.

Security Considerations The security considerations for , and apply to this specification as well. According to the most recent security analysis publications, Ascon did not show any security vulnerabilities so far and the best attacks target the initialization of Ascon reduced to 7 (out of 12) rounds, concluding that Ascon has a security margin of 5 rounds (42 % of the 12 rounds). Refer to the Ascon's List of Published Analysis section at for more details.

IANA Considerations

Additions to Existing Registries

New COSE Algorithms IANA is requested to add the following entries to the COSE Algorithms Registry. The following completed registration templates are provided as described in and .

Ascon-AEAD128 for COSE Name: Ascon-AEAD128 Value: TBD (requested assignment 35) Description: CBOR Object Encryption Algorithm with Ascon-AEAD128 Capabilities: [kty] Reference: FIPS XXX Recommended: Yes

New JOSE Algorithms IANA is requested to add the following entries to the JSON Web Signature and Encryption Algorithms Registry. The following completed registration templates are provided as described in .

Ascon-AEAD128 for JOSE Algorithm Name: Ascon-AEAD128 Algorithm Description: Ascon-AEAD128 as described in FIPS XXX. Algorithm Usage Location(s): enc JOSE Implementation Requirements: Optional Change Controller: IESG Specification Document(s): FIPS XXX Algorithm Analysis Documents(s): n/a

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. JSON Web Encryption (JWE) represents encrypted content using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries defined by that specification. Related digital signature and Message Authentication Code (MAC) capabilities are described in the separate JSON Web Signature (JWS) specification. A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification. This specification registers cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications. It defines several IANA registries for these identifiers. 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. 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. IANA IANA

Examples This appendix provides some examples of various Ascon-AEAD128 Encryptions with COSE and JOSE

COSE

Simple Ascon-AEAD128 Encryption

Direct Ascon-AEAD128 Encryption with HKDF-SHA-256

JOSE

Direct Compact JWE structure using Ascon-AEAD128