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


From: Harry Halpin <hhalpin@w3.org>
Date: Tue, 29 Jan 2013 09:09:32 -0000 (GMT)
Message-ID: <9d95f69e2d214c588e6c6540eddd84c5.squirrel@webmail-mit.w3.org>
To: "Ryan Sleevi" <sleevi@google.com>
Cc: "Richard L. Barnes" <rbarnes@bbn.com>, "Justin Troutman" <justin.troutman@gmail.com>, public-webcrypto-comments@w3.org
> 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]).

By W3C process, implementation features that are not at risk should have
two inteoperable implementations.

We could specify more in a registry (either the wiki or IANA option are
both still on table), as I do agree specification is cheap and that the
IANA Specification Required doc is fine with me, given what Ryan already
wrote re specifying in the API.

My gut feeling is that the W3C API should list identifiers for algorithms
they plan to support at this stage, as WebApp devleopers often use the API
for a reference and will get irrirated if things in the API don't seem to

For a latest version of possibly unimplemented algorithms, one should
check the registry and we should clearly note the whatever is in the API
has *test-cases* dated to the date of the last test-case doc, while this
is not the case with the registry. The registry would then have
identifiers that would be "use-at-your-own-risk"

Does that make sense?

>> [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 Tuesday, 29 January 2013 09:09:36 UTC

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