| Internet-Draft | COSE AES-CMAC | July 2026 |
| Sipos | Expires 30 January 2027 | [Page] |
The CBOR Object Signing and Encryption (COSE) specification defines structures for generating, conveying, and verifying Message Authentication Code (MAC) tags. This document registers code points for using the Advanced Encryption Standard (AES) block cipher in Cipher-based Message Authentication Code (CMAC) mode within those COSE structures. Specifically, these uses are for computing MAC tag values with no additional parameters.¶
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 30 January 2027.¶
Copyright (c) 2026 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.¶
The base CBOR Object Signing and Encryption (COSE) specification [RFC9052] defines two message types for Message Authentication Code (MAC) parameters and results: COSE_Mac and COSE_Mac0.
These messages are parameterized on an algorithm identifier used to generate and verify the MAC tag.
This document defines new fully specified COSE algorithm code points for the use of Advanced Encryption Standard (AES) block cipher [FIPS-197] in Cipher-based Message Authentication Code (CMAC) mode [SP800-38B] to compute a MAC tag.¶
These COSE algorithm code points are "fully specified" in accordance with [RFC9864], meaning they rely on no extra parameters to determine their exact operation. The COSE algorithm code point along with the shared secret key is sufficient to generate or verify the MAC tag.¶
The use of CMAC is an alternative to the Hash-based Message Authentication Code (HMAC) family of algorithms registered by the base COSE specification in Section 3.1 of [RFC9053]. CMAC relies exclusively on a block cipher instead of the HMAC use of a cryptographic hash function. For some implementations, cipher-based MAC can be hardware accelerated.¶
To avoid confusion, the AES-CMAC algorithm family specified in this document is distinct from the "AES-MAC" (also known as "AES-CBC-MAC") algorithm family from Section 3.2 of [RFC9053].¶
This document does not define any new cryptographic algorithms or functions. It only defines code points in a COSE registry so that the AES-CMAC algorithm family can be used in COSE messages.¶
This document does not address the use of CMAC for any other purposes than to compute a fixed-length MAC tag. These registered code points are not to be used as a pseudorandom function (PRF) or key-derivation function (KDF).¶
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.¶
While the CMAC mode [SP800-38B] can be used with any underlying encryption block cipher, this document focuses on its use with the AES cipher referred to as AES-CMAC.¶
For the sake of adhering to COSE best practice [RFC9864] about fully specifying what gets assigned a COSE "algorithm" code point, AES-CMAC will be treated as an algorithm family with a single COSE code point referring to the algorithm family along with a specific set of parameter values. The parameters associated with AES-CMAC family are: key length and tag length.¶
This document registers code points for the commonly used key lengths of 128 and 256 bits and tag lengths of 96 and 128 bits. The 128-bit tag happens to be the longest possible tag length while the 96-bit tag is a truncated form. These tag lengths are consistent with the use cases for single-use keys and limited-use keys (see Section 3.1) and with the use of AES-CMAC in IPsec [RFC4494].¶
| Name | COSE Value | Algorithm Family | Key Length | Tag Length |
|---|---|---|---|---|
| AES-CMAC 128/96 | TBA1 | AES-CMAC | 128 | 96 |
| AES-CMAC 256/96 | TBA2 | AES-CMAC | 256 | 96 |
| AES-CMAC 128/128 | TBA3 | AES-CMAC | 128 | 128 |
| AES-CMAC 256/128 | TBA4 | AES-CMAC | 256 | 128 |
When using a COSE key for these algorithms, the following checks are made:¶
This document does not define any new behavior of the AES-CMAC family, so all of the applicable considerations of AES [FIPS-197] and CMAC [SP800-38B] apply when the algorithm family is used in COSE.¶
The CMAC mode of AES is approved by US NIST FIPS 140 [FIPS-140]. The pre-existing uses of AES-CBC-MAC in COSE [RFC9053] are not approved by FIPS 140.¶
From analysis of Appendix B of [SP800-38B] performed in 2024 [Ericsson], an "effective tag length" in bits can be computed for the 128-bit AES block length as¶
T_eff = 128 - 2 * log2(q)¶
where the factor "q" is the message span of each key (number of messages for which a tag is generated).¶
This means that only for single-use keys is the effective tag length is the actual tag length.
For the NIST recommended limit of q = 2^48, the effective tag length becomes shortened to only 48 bits.¶
The analysis itself [Ericsson] recommends an effective tag length no less than 64 bits (i.e., equivalent to a 64-bit ideal MAC).
This translates to a message span limit of q < 2^32, meaning a single key is limited to generate MAC tags for fewer than 2^32 messages.
For a 96-bit effective tag length, the limit becomes fewer than 2^16 messages.¶
This section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding registration of code points in accordance with BCP 26 [RFC8126].¶
A new set of entries have been added to the "COSE Algorithms" registry [IANA-COSE] with the following parameters:¶
This following subsections include examples of tagged COSE_Mac0 messages using algorithms defined in this document. Each of these examples is self-contained, but they are inspired by the examples in Appendix C of [RFC9052]. These examples all use the extended diagnostic notation (EDN) from Appendix G of [RFC8610].¶
NOTE to the RFC Editor: These examples use algorithm code points suggested in Section 4.1 but not yet allocated. ¶
This example uses the truncated tag variant of AES-CMAC with the following 256-bit content key and an embedded payload identical to the example in Appendix C.5.1 of [RFC9052].¶
{
/ kty / 1: 4, / symmetric /
/ kid / 2: 'ExampleA.1',
/ alg / 3: 36, / AES-CMAC 256//96 /
/ ops / 4: [9, 10], / MAC create, MAC verify /
/ k / -1: h'849b57219dae48de646d07dbb533566e976686457c1491be3a76
dcea6c427188'
}
¶
When used with a COSE_Mac0 message, the MAC_Structure has the following EDN.¶
[
"MAC0", h'a1011824', h'',
h'546869732069732074686520636f6e74656e742e'
]
¶
The full COSE_Mac0 message thus has the following EDN.¶
17([
<< {
/ alg / 1: 36 / AES-CMAC 256//96 /
} >>,
{
/ kid / 4: 'ExampleA.1'
},
h'546869732069732074686520636f6e74656e742e', / payload /
h'c17c159da967a22e6f44d48d' / tag /
])
¶
This example uses the full-length tag variant of AES-CMAC with the following 256-bit key-derivation key (KDK) and a detached payload identical to the example in Appendix C.5.1 of [RFC9052]. Using a KDK with a deterministic salt enables the content key to be single-use and satisfy the maximum effective tag length as described in Section 3.1.¶
[
{
/ kty / 1: 4, / symmetric /
/ kid / 2: 'ExampleA.2',
/ alg / 3: -11, / direct+HKDF-SHA-512 /
/ ops / 4: [7], / derive key /
/ k / -1: h'5e1047c9b428ee26d2c1059737301756effbeec673f283cf
f992f132d6a3cb8a'
},
{ / derived content key /
/ kty / 1: 4, / symmetric /
/ alg / 3: 38, / AES-CMAC 256//128 /
/ ops / 4: [9, 10], / MAC create, MAC verify /
/ k / -1: h'723d4eaa03449122524378322e0806196d19675365294a05
7513e677ce3401e3'
},
]
¶
When used with a COSE_Mac message, the MAC_Structure has the following EDN.¶
[
"MAC", h'a1011826', h'',
h'546869732069732074686520636f6e74656e742e'
]
¶
The content key is derived from a COSE_KDF_Context with the following EDN.¶
[38, [null, null, null], [null, null, null], [256, h'a1012a']]¶
The full COSE_Mac message thus has the following EDN.¶
97([
<< {
/ alg / 1: 38 / AES-CMAC 256//128 /
} >>,
{},
null, / detached payload /
h'9360a9b5a832fc5ac7ae1d94806735df', / tag /
[
[ / recipient /
<< {
/ alg / 1: -11 / direct+HKDF-SHA-512 /
} >>,
{
/ kid / 4: 'ExampleA.2',
/ salt / -20: h'673b4e76'
},
null
]
]
])
¶
This section is to be removed before publishing as an RFC.¶
[NOTE to the RFC Editor: please remove this section before publication, as well as the reference to [RFC7942] and [github-pycose].]¶
This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in [RFC7942]. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations can exist.¶
An implementation of the algorithms added by this document is made in a fork of the pycose library [github-pycose].
This implementation was used to produce the examples in this document.¶
This section is to be removed before publishing as an RFC.¶
Version history of this document:¶
draft-sipos-cose-cmac-02.¶