Re: CMAC.

While we could define it, I would think its unlikely to see it make it
through Last Call/CR stages.

I say this because as discussed during the initial chartering, part of the
premise/justification was to expose user agents already existing
cryptographic stacks, due to having to implement TLS. CMAC is not generally
a part of those stacks - in fact, for all major UAs and crypto stacks, I am
only aware of Windows 8+CNG supporting CMAC. As a result, any exposure of
CMAC would first require implementing it, and that seems unlikely given it
has not been implemented already (or backported to other Windows versions,
in the case of CNG).

The same issues exist for algorithms like SEED. Yes, it can be argued there
is value in specifying how it should behave if it were to be implemented,
but on the pragmatic side, its unlikely to survive CR, based on the state
of the world today.

If other implementers feel differently, please chime in.
On Jan 27, 2013 7:47 AM, "Justin Troutman" <justin.troutman@gmail.com>
wrote:

> Good morning,
>
> Pardon me if I've sent this through before.
>
> Is there any reason CMAC isn't defined in the specifications? CMAC will
> allow you to recycle the block cipher you're already using (AES), which
> reduces the number of primitives necessary to encrypt and authenticate; in
> turn, this adds a bit of cleanliness to the code, which should be a primary
> focus of any attempt at real-world cryptographic design. Security-wise,
> HMAC and CMAC are both SUF-CMA, so I'm not concerned about that; it just
> seems logical to give your block cipher the opportunity to authenticate too.
>
> Cheers,
>
> Justin
>