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 matter. Thank you On May 24, 2013 6:55 AM, "Nikos Mavrogiannopoulos" < nikos.mavrogiannopoulos@esat.kuleuven.be> 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