Re: Key usages future compatibility

My concern is that usages inherently serve to restrict the allowable
operations of a key.

If a usage is not supported by a WebCrypto implementation, we are
potentially creating/importing an unusable key, or a key with unknown side
effects.

While I certainly understand and appreciate the point you raise, from a
security perspective, it seems most appropriate to reject anything unknown,
rather than to silently accept and/or drop, wouldn't you agree?
On Nov 1, 2013 10:55 AM, "Alexey Proskuryakov" <ap@webkit.org> wrote:

>
> Currently, WebCrypto specifies that usages is an array of enum values.
> This means that when an unknown value is encountered, the implementation
> raises a typeError exception, per WebIDL.
>
> I think that this is problematic. There is no reason to prevent web
> applications from creating Key objects with allowed usages added by a
> future version of the spec. The Key object can be saved to permanent
> storage, and even if the current version of the browser doesn't understand
> a particular usage, a future version will. We should store the whole set,
> not a currently supported slice.
>
> Even for non-persistent keys, I don't see a reason to completely reject an
> importKey or generateKey operation simply because the allowed usages
> include something the browser doesn't know about. As a web site adopts
> future WebCrypto features, key creation will raise an exception in old
> browsers, breaking the site's existing features - as opposed to only having
> new features that use new WebCrypto functionality broken.
>
> It seems that WebCrypto should explicitly specify an appropriate behavior
> for unknown usage strings, and not rely on enum behavior specified by
> WebIDL.
>
> See also: <https://www.w3.org/Bugs/Public/show_bug.cgi?id=22548>. Given
> the considerations above, the proposed solution in this bug wouldn't work,
> we can't just store operations as a bitfield.
>
> - WBR, Alexey Proskuryakov
>
>
>