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

Re: [W3C WebCrypto API WG] Key discovery

From: Ryan Sleevi <sleevi@google.com>
Date: Fri, 5 Apr 2013 15:05:12 -0700
Message-ID: <CACvaWvZ0-F-6nBiBSDLcn01HO1on8SLjbAhL6DrkM4uds3RmXQ@mail.gmail.com>
To: Hutchinson Michael <Michael.Hutchinson@gemalto.com>
Cc: Mark Watson <watsonm@netflix.com>, Lu HongQian Karen <karen.lu@gemalto.com>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>
On Fri, Apr 5, 2013 at 3:00 PM, Hutchinson Michael
<Michael.Hutchinson@gemalto.com> wrote:
> Ryan,
> Thanks for reminding us to look at the charter...
> The primary scope includes: "Primary API Features in scope are: key generation, encryption, <SNIP>, and key storage and control beyond the lifetime of a single session."
> AFAIK, there is no mechanism to support "control beyond the lifetime of a single session" within "window.crypto".

This is not true. Keys are defined as being structured clonable. Your
existing web storage mechanisms support this.

This has been extensively discussed within this WG and during our F2F.

> We are attempting to add the getKeys() method within "window.cryptkeys" to handle all keys. This will include both keys whose lifetime is within or beyond a single session and key that were previously provisioned. We therefore believe that this is within the scope. This proposal is independent of the mechanism of key storage.

You're conflating two very distinct things, which is why I suggest
it's outside the scope of the charter.

Keys whose lifetime is beyond a single session is already supported.

Keys that were previously provisioned have already been identified as
a "nice to have", but not a primary deliverable. I applaud Mark's work
on the Key Discovery spec as an attempt to explore how to support
pre-provisioned keys, and in a very narrow and reasonable scope (see
the original discussions about 'globally unique key IDs' and compare
with the current spec to see how much simpler it is now)

Non-opaque key identification - which this unquestionably is - is very
clearly called out as out of scope.

> You are correct that:
> The "Issuer" field is underspecified. We will work on defining it more specifically.
> The "isPrivate" field concerns with access control, which is out of the scope. More on this later...
> Regards,
> Michael and Karen
> -----Original Message-----
> From: Ryan Sleevi [mailto:sleevi@google.com]
> Sent: Thursday, April 04, 2013 6:37 PM
> To: Lu HongQian Karen
> Cc: Mark Watson; public-webcrypto@w3.org; Hutchinson Michael
> Subject: Re: [W3C WebCrypto API WG] Key discovery
> Issuer is underspecified, and as such, not possible to implement.
> Further, this seems to directly conflict with the charter, which states:
> "Out of scope: features including special handling directly for non-opaque key identification schemes, access-control mechanisms beyond the enforcement of the same-origin policy, and functions in the API that require smartcard or other device-specific behavior"
> This requires both handling for non-opaque key identification scheme
> ("issuer") as well as an access control mechanism ("isPrivate")
> As such, we do not support the WG taking on this item.
> On Thu, Apr 4, 2013 at 4:21 PM, Lu HongQian Karen <karen.lu@gemalto.com> wrote:
>> Hi Mark,
>> We would like to suggest expanding the key discovery specification by adding an API for discovering pre-provisioned cryptographic keys via any of their attributes. This gives web applications a mean to find pre-provisioned keys whose names are unknown to them.
>> The contribution is attached for review.
>> Regards,
>> Karen and Michael
Received on Friday, 5 April 2013 22:05:40 UTC

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