W3C home > Mailing lists > Public > public-webcrypto-comments@w3.org > January 2013


From: Richard Barnes <rbarnes@bbn.com>
Date: Mon, 28 Jan 2013 12:31:00 -0500
Cc: Justin Troutman <justin.troutman@gmail.com>, public-webcrypto-comments@w3.org
Message-Id: <7D7C295B-C9D9-4EFE-ADE9-186C1F81485B@bbn.com>
To: Ryan Sleevi <sleevi@google.com>
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
Received on Monday, 28 January 2013 17:31:27 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:12:49 UTC