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

Re: crypto-ISSUE-8 (key neutering): Making sure we describe the clean key neutering [Web Cryptography API]

From: Ryan Sleevi <sleevi@google.com>
Date: Wed, 1 Aug 2012 09:17:56 -0700
Message-ID: <CACvaWvbVDWE=R4Lyo1G4OeQeNi+CZvU5ox9dbE-_zPC4tKRkMA@mail.gmail.com>
To: Web Cryptography Working Group <public-webcrypto@w3.org>
On Wed, Aug 1, 2012 at 8:56 AM, Web Cryptography Working Group Issue
Tracker <sysbot+tracker@w3.org> wrote:

> crypto-ISSUE-8 (key neutering): Making sure we describe the clean key
> neutering [Web Cryptography API]
>
> http://www.w3.org/2012/webcrypto/track/issues/8
>
> Raised by: Virginie GALINDO
> On product: Web Cryptography API
>
> During the Summer F2F meeting the group raised the point that once the key
> object would be defined, together with the different possible states, it
> would be key to describe properly the key neutering.
>
>
>
>
Just a slight clarification - I don't believe consensus was reached that we
necessarily need neutering. The outstanding question of how much the
underlying objects represented real/expensive resources and whether or not
they were going to be Transferrable (passable to Workers).

For example, in WebGL, the GL Contexts are not transferable, but the
ArrayBuffers are. Thus neutering ArrayBuffers makes sense, as opposed to
having to allocate a second copy of the memory for use on the worker. The
same applies to File objects.

For CryptoOperation, because it has a .result, perhaps it makes more sense
to make that object neuterable. The key may be an opaque handle
(transferrable or not) that the underlying user agent can determine the
sharing/performance semantics, since the semantics are slightly contingent
upon how the user agent implements the crypto.
Received on Wednesday, 1 August 2012 16:18:24 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:01:25 UTC