W3C home > Mailing lists > Public > public-webcrypto@w3.org > April 2013

ISSUE-35 - Use cases for Wrap/Unwrap

From: Ryan Sleevi <sleevi@google.com>
Date: Thu, 25 Apr 2013 15:07:18 -0700
Message-ID: <CACvaWvZESnVcKN+XEy8OcakLxjrg5yw=fLsdDU9Y3RoZQTSayQ@mail.gmail.com>
To: "public-webcrypto@w3.org" <public-webcrypto@w3.org>
As discussed at the F2F, in order to understand whether wrap/unwrap
makes sense within the Web Crypto API (that is, independent of any
other specifications), we need to gather use cases - particularly
those that show this is something that cannot be accomplished by

A recap of some of the important points to consider:
 - A key that is not exportable is a key that is not wrappable
 - Conversely, a key that is wrappable is in fact exportable, as an
'attacker' can control the wrapping key used under the current
 - The Web Crypto API specifically makes no statements about key
storage or implementation. We have intentionally, as part of the API
design, avoided any such discussion of cryptographic modules or other
intra-API boundaries.

For example, on
, the following use case was proposed:

"This could be a use case for key wrap/unwrap, however. Imagine a
service with long-lived keys (e.g., a secure file storage service)
that can be accessed from multiple UA instances. Then the server would
want to have the client that generates a long-lived key cache an
encrypted copy on the server (wrap), then provision those keys out to
UAs (unwrap)."

Such a use case can be satisfied today using our existing primitives
(export+encrypt, decrypt+import), so wrap/unwrap does not add any
unique value here to something that can be polyfilled.

Ideally, use cases will also target something along the lines of "This
is impossible to do with the API without the assistance of the UA,
because of X", since that helps identify the missing functionality
from polyfills.

For example, the Web Crypto API itself is impossible to do without
assistance of the UA because of:
  - Lack of strong entropy (hence getRandomValues)
  - Lack of assurances regarding constant time (as a virtue of JS)
Received on Thursday, 25 April 2013 22:07:45 UTC

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