Ascon-AEAD128 for COSE and JOSE

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 13 March 2026.¶

Copyright Notice

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. 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 [NIST.SP.800-232] introduces a suite of algorithms consisting of 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 COSE and JOSE for content encryption.¶

2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

3. Ascon algorithms

In the scope of this document, only the authenticated encryption scheme of the Ascon family is allowed for, namely Ascon-AEAD128. Ascon-AEAD128.enc and Ascon-AEAD128.dec algorithms are parametrized by the key size k, the nonce size n, the tag size t, the rate r, and the internal round numbers a and b. [NIST.SP.800-232] specifies the Ascon-AEAD128 algorithm with the following parameters:¶

In addition, [NIST.SP.800-232] allows the tag truncation. The standard permits tag sizes λ, where 32 <= λ <= 128 bits. Tags of less than 64 bits SHALL only be selected after a careful risk analysis.¶

Since COSE can be used in different scenarios, this document requests to register three variations of Ascon-AEAD128 in [IANA.cose] with common tag sizes of 32, 64, and 128 bits (see Table 2). Using the 32-bit variation is discouraged for typical scenarios and SHOULD be introduced only in extremely constrained use cases with justified security.¶

In COSE, keys may be obtained from either a key structure or a recipient structure [RFC9052].¶

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 variation of 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.¶

COSE encryption and decryption with Ascon-AEAD128 is done in accordance with Section 5.3 of [RFC9052].¶

Also, this document requests the registration of the Ascon-AEAD128 algorithms in [IANA.jose] with 64-, and 128-bit tags (see Table 3). Unlike COSE, there is no 32-bit tag variation since JSON Web Encryption (JWE) structure is not intended to be used in extremely constrained scenarios.¶

JOSE encryption and decryption processes with Ascon-AEAD128 should follow Section 5 of [RFC7516].¶

Implementations that are encrypting or decrypting MUST validate that the key type, key length, and algorithm are correct and appropriate for the entities involved.¶

4. 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-AEAD128 encryption/decryption functions, IV is the constant defined for each Ascon algorithm used as a part of state initialization.¶

However, [IANA.cose] 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 SHALL refer to the N argument of the corresponding Ascon function.¶

On the other hand, JSON Web Signature and Encryption Header Parameters registry at [IANA.jose] defines both Nonce Header Parameter ("nonce") and Initialization Vector Header Parameter ("iv"). However, the "nonce" parameter is intended to be used only with signatures. Therefore, in JOSE, "iv" parameters SHALL 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.¶

5. Security Considerations

The security considerations for [NIST.SP.800-232], [RFC7516], [RFC7517] and [RFC9052] 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). More details are available at List of Published Analysis section of [asconv1.2-nist].¶

6. IANA Considerations

7. References

Appendix A. Examples

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

{
  "plaintext": "This is the content.",
  "nonce_hex": "00000000000000000000000000000000",
  "AAD_hex": "8367456E637279707443A1010140",
  "CEK_hex": "849B57219DAE48DE646D07DBB533566E",
  "Encrypt0_hex": "8344A1011823A1055000000000000000000000000000000000582461484F95FC36BD13D7EFCA1C370EE3B6A1125770C8878467D3AE466C7C6CC4F4918BAA96",
  "Encrypt0_diag": "[h'A1011823', {5: h'00000000000000000000000000000000'}, h'61484F95FC36BD13D7EFCA1C370EE3B6A1125770C8878467D3AE466C7C6CC4F4918BAA96']"
}

{
  "plaintext": "This is the content.",
  "nonce_hex": "00000000000000000000000000000000",
  "AAD_hex": "8367456E637279707443A1010140",
  "CEK_hex": "849B57219DAE48DE646D07DBB533566E",
  "key": {
    "kid": "abcdef",
    "kty": "Symmetric"
  },
  "Encrypt": "8444A1011823A10550000000000000000000000000000000005824D3468D9110A2C3005E82D48628CD462BBD8721FBABE883A7743F191AC81CA8D6BBED5E44818340A20125044661626364656640",
  "Encrypt_diag": "[h'A1011823', {5: h'00000000000000000000000000000000'}, h'D3468D9110A2C3005E82D48628CD462BBD8721FBABE883A7743F191AC81CA8D6BBED5E44', [[h'', {1: -6, 4: h'616263646566'}, h'']]]"
}

{
  "plaintext": "This is the content.",
  "nonce_hex": "00000000000000000000000000000000",
  "AAD_hex": "8367456E637279707443A1010140",
  "CEK_hex": "849B57219DAE48DE646D07DBB533566E",
  "key": {
    "kid": "abcdef",
    "kty": "Symmetric"
  },
  "salt": "abcdefghijlmnopq",
  "Encrypt": "8444A1011823A10550000000000000000000000000000000005824B80EA16F0EBCC9F25502EE1D992D23C4E7984E2919AD6C3E37581FB099DB5855F1490ECF818340A3012933506162636465666768696A6C6D6E6F7071044661626364656640",
  "Encrypt_diag": "[h'A1011823', {5: h'00000000000000000000000000000000'}, h'B80EA16F0EBCC9F25502EE1D992D23C4E7984E2919AD6C3E37581FB099DB5855F1490ECF', [[h'', {1: -10, -20: h'6162636465666768696A6C6D6E6F7071', 4: h'616263646566'}, h'']]]"
}

{
  "plaintext": "This is the content.",
  "CEK_hex": "849B57219DAE48DE646D07DBB533566E"
}

{
  "protected": "eyJhbGciOiJkaXIiLCJlbmMiOiJBc2Nvbi1BRUFEMTI4In0", \* {"alg": "dir", "enc": "Ascon-AEAD128"} *\
  "aad": "g2dFbmNyeXB0Q6EBAUE",
  "encrypted_key": "",
  "iv": "AAAAAAAAAAAAAAAAAAAAAA",
  "tag": "EihrljYH6xrt08Ae9Slqzw",
  "ciphertext": "dMbnoonoAEUph2N4KWIj_i_L-oo"
}

{
  "protected": "eyJhbGciOiJBMTI4S1ciLCJlbmMiOiJBc2Nvbi1BRUFEMTI4Iiwia2lkIjoiYWJjZGVmIn0", \* {"alg":"A128KW","enc":"Ascon-AEAD128","kid":"abcdef"} *\
  "aad": "g2dFbmNyeXB0Q6EBAUE",
  "header": {
    "alg": "A128KW",
    "kid": "abcdef"
  },
  "encrypted_key": "V4d7CMPzWA3ntHiL4gcN5EYoQJX2t-Gw",
  "iv": "AAAAAAAAAAAAAAAAAAAAAA",
  "tag": "9vY9jDG2LZOVmHsD6kHgkA",
  "ciphertext": "wZJfEzhC59fiqtnKtYpXqCi0-Xo"
}

Authors' Addresses