W3C home > Mailing lists > Public > public-webcrypto@w3.org > November 2012

Re: ISSUE-31 Re: KeyStorage and Pre-provisioned Keys: A proposal

From: Ryan Sleevi <sleevi@google.com>
Date: Mon, 19 Nov 2012 11:30:13 -0800
Message-ID: <CACvaWvayZOnk9S+JrFEgvT-D9CkBy6gfVi7ea_yU1HjLVmHcqg@mail.gmail.com>
To: Mark Watson <watsonm@netflix.com>
Cc: Harry Halpin <hhalpin@w3.org>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>
On Mon, Nov 19, 2012 at 10:27 AM, Mark Watson <watsonm@netflix.com> wrote:
>>
>> As mentioned previously, this does not sound like a suitable approach
>> to addressing the technical concerns raised.
>
> You mentioned that you did not like overloading the existing import/export, but I didn't see any comments from you against the idea of casting different query/discovery mechanisms as 'algorithms'. Do you object to that approach generally ? Could you elaborate ?
>
> ůMark

Every browser vendor that has commented has (rightfully) raised
concerns about optional algorithms. "Optional" is generally seen as
bad for the web platform. I've already received suggestions from some
that the way to address algorithm regulatory/technical concerns
motivating algorithm optionality would be the wholesale
enabling/disabling of the feature, rather than having algorithms be
optional. This is conceptually similar to WebGL, in which if a video
card does not support feature X, the entire WebGL suite is disabled
(or the browser software-fills it in). While not wanting to re-open
the algorithm debate at this point, I provide it as a reasonable point
to demonstrate the growing concern about how effective the API will be
with optionality, and why more optionality is a non-starter.

As related previously, I've hopefully made it clear my own view that a
model of optionality - modeled after algorithms or otherwise - is
pretty much a non-starter for the main spec from an implementer's
perspective, for reasons such as above. If the WG reaches consensus to
going further down the rabbit hole of "optionality", then we should be
talking modules and separate specs (each of which MUST be wholly
implemented), rather than a giant mix-and-match free for all in a
single spec.

Regardless though, given the significant (complete?) overlap between
pre-provisioned and pre-existing keys, it seems like a single, common,
mandatory API is absolutely possible to devise.
Received on Monday, 19 November 2012 19:30:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:14 UTC