COSE WG,
I have submitted a very short individual draft [1] to allocate code points
for AES-CMAC having strengths equivalent to existing AES-CBC-MAC
registrations. As the abstract and introduction makes clear, the point of
this registration is to provide a FIPS-approved ciper-based MAC. As Lijun
mentions, the benefit of the CMAC is hardware acceleration. But as with all
registered algorithms they are not mandatory-to-use for anyone.

Brian S.

[1] https://datatracker.ietf.org/doc/draft-sipos-cose-cmac/

On Fri, Oct 31, 2025 at 5:40 PM Lijun Liao <[email protected]> wrote:

> Compared to HMAC, KMAC and ASCON, AES-CMAC is more widely supported in
> many MCUs due to the fact that no extra primitive technologies except AES
> is required.
>
> So for the embedded world e.g. automotive, supporting AES-CMAC in COSE is
> wished.
>
> Lijun
>
> On 31. Oct 2025, at 18:25, Robert Moskowitz <rgm-sec=
> [email protected]> wrote:
>
> You have HMAC, KMAC, and ASCON.
>
> You want lightweight?  Go with ASCON.
>
> HMAC is two keyed MACs, KMAC is one.  HMAC can be lighter in memory with
> KMAC faster.
>
> I generally run away from AES-CMAC.  It has edge cases where there be
> dragons.  Thus it has been years since I have don't anything with CMAC.
>
> On 10/31/25 12:55 PM, Sipos, Brian J. wrote:
>
> WG,
> In doing some background research for a minimalist COSE profile I ran into
> the case that the existing registered AES-MAC algorithm family is not on
> the US NIST FIPS 140 approved list [1] but the AES-CMAC family is approved.
> I saw some COSE discussion on this going back to 2015 [2] and 2018 [3] with
> the conclusion there that AES-CBC-MAC was more widely supported in
> constrained environments. Since that time, it appears that CMAC has been
> more solidified as the preferred cipher-based MAC technique.
>
> Is there any COSE WG appetite for registering a FIPS-approved AES-CMAC
> algorithm family? This would be a relatively small addition, probably two
> code points, and because this is not a technical or security limitation of
> the existing AES-MAC registrations I think they would be left in-place and
> not deprecated.
>
> I can bring this up at next week’s IETF if there is any interest.
>
> Thanks for any feedback,
> Brian S.
>
> [1]
> https://csrc.nist.gov/projects/cryptographic-module-validation-program/sp-800-140-series-supplemental-information/sp800-140c
> [2]
> https://mailarchive.ietf.org/arch/msg/cose/GwP_6EgbzTkzXGh36WhX0nomhT8/
> [3]
> https://mailarchive.ietf.org/arch/msg/cose/yiLtOdsw6RXC-iHdNHJKGWgfUEs/
>
>
> _______________________________________________
> COSE mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>
>
> _______________________________________________
> COSE mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>
>
> _______________________________________________
> COSE mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>
_______________________________________________
COSE mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to