W3C home > Mailing lists > Public > public-webcrypto@w3.org > March 2014

Re: WorkerCrypto interface concerns from Microsoft

From: Ryan Sleevi <sleevi@google.com>
Date: Fri, 7 Mar 2014 13:52:30 -0800
Message-ID: <CACvaWvZcgD-ctqone1YqX-RjvbHokw8-YCiBebEjPUCoUn5nPA@mail.gmail.com>
To: Israel Hilerio <israelh@microsoft.com>
Cc: "public-webcrypto@w3.org" <public-webcrypto@w3.org>
Just to close the loop on this -
https://dvcs.w3.org/hg/webcrypto-api/rev/9f1f378595fc should make it clear
that we're only exposing the Promises interface on WorkerCrypto - along
with the RandomSource.

It just means window.crypto behaves identical to worker.crypto, which
should address all use cases.

The previous blocking issues were:
1) Should we define sync interfaces
2) How do we handle multi-threaded Key access

We resolved point 1 by saying "No"
  - In the future, if we wish to do so, it can be as part of / extension to
the Promise interface" (eg: imagine a promise.wait() method)
We resolved point 2 by removing the Key Storage (long ago), allowing Keys
to be handled in IDB.
  - All cryptographic state is handled within the Promise, which isn't
transferrable between workers
  - Key tainting is no longer required, by virtue of moving the hashed
attributes into key generation, so we don't have synchronization risks there
  - Regardless, by virtue of the Promises() interface, implementations can
take their own approach to scheduling the work for promises




On Tue, Feb 25, 2014 at 9:56 AM, Israel Hilerio <israelh@microsoft.com>wrote:

>  Group,
>
>
>
> After yesterday’s call, I had an opportunity to get clarification from
> Ryan on the work related to the WorkerCrypto interface [1].  From my new
> understanding, the intent is to surface the SubtleCrypto interface and its
> async behavior to a Worker so that they can perform cryptographic
> operations as first-class citizens.  This approach won’t allow for any
> mutation of DOM objects.
>
>
>
> This new understanding removed my initial concern about the section. This
> seems very reasonable and I don’t see a need to put this section at Risk.
> However, I would like to see this clarification be part of the spec.
>
>
>
> Israel
>
>
>
> [1]
> https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#WorkerCrypto-interface
>
>
>
Received on Friday, 7 March 2014 21:52:58 UTC

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