Re: comments on web crypto API: General comments on the document [6/6]

Thank you for your feedback. It has been received.

When this group was chartered, it was under the basis of exposing browsers
*existing* cryptographic functionality.

As you are no doubt aware, cryptography is heavily regulated, both in terms
of export and in terms of implementation. An API that cannot be implemented
atop existing libraries and functionality represent an API that fails to
meet the goals set forth early on, and thus represents significant hurdles
to adoption.

The design choices here are based on designs that have the widest
interoperability. If you will suffer a metaphor, this is akin to WebGL
being (roughly) akin to OpenGL/ES, as opposed to DirectX (limited to a
single platform), or attempting to invent an entirely new API simply
because "newer is better."

While your feedback has been received, because it has been discussed at
great length in this WG before, I do not see any changes being made on this

Thank you
On May 24, 2013 6:55 AM, "Nikos Mavrogiannopoulos" <> wrote:

> On 2013-05-23 18:57, Ryan Sleevi wrote:
>  This matches the existing APIs and cryptographic libraries in use by
>> browsers - which was a key use case in the chartering of this group
>> and design of this API - in that all parameters must be specified up
>> front so that an implementation can accurately represent whether an
>> operation is supported.
>> Implementations built on PKCS#11, for example (which include both
>> Firefox and Chromium) are not able to change IV midstream.
> I do not think that a new API designed in 2013 should contain the same
> issues and limitations as another API designed in 1995. Otherwise, why not
> just standardize the PKCS #11 API in javascript?
> regards,
> Nikos

Received on Friday, 24 May 2013 14:43:33 UTC