Re: CMAC.

An identifier with no implementation is significantly worse for developers
than no identifier at all. The bar is what it is in our charter -
implementation, not specification, required.
On Jan 28, 2013 9:30 AM, "Richard Barnes" <rbarnes@bbn.com> wrote:

> That, of course, begs the question of what the bar is for algorithms to
> get identifiers for use with this spec.
>
> Is there a reason *not* to create an identifier for CMAC?  Identifiers are
> cheap, and developers are always going to have to deal with unavailable
> algorithms.
>
> I don't really have a preferred outcome here, but I think it would be
> useful to clarify how we decide what's in/out.  FWIW, my initial
> inclination, as suggested above, would be for something like Specification
> Required (to use the IANA term [1]).
>
> [1] <http://tools.ietf.org/html/rfc5226#section-4.1>
>
>
>
> On Jan 27, 2013, at 3:02 PM, Ryan Sleevi <sleevi@google.com> wrote:
>
> > 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
>
>