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

RE: [W3C WebCrypto API WG] Key discovery

From: Hutchinson Michael <Michael.Hutchinson@gemalto.com>
Date: Sat, 6 Apr 2013 00:00:26 +0200
To: Ryan Sleevi <sleevi@google.com>, Mark Watson <watsonm@netflix.com>, Lu HongQian Karen <karen.lu@gemalto.com>
CC: "public-webcrypto@w3.org" <public-webcrypto@w3.org>
Message-ID: <AA393B9CFBFD084C9700F560930980040119B3142E80@CROEXCFWP03.gemalto.com>
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". 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 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:00:52 UTC

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