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

[W3C Web Crypto WG] functional features list in draft API and issue tracker

From: GALINDO Virginie <Virginie.GALINDO@gemalto.com>
Date: Wed, 22 Aug 2012 16:38:05 +0200
To: Ryan Sleevi <sleevi@google.com>
CC: "public-webcrypto@w3.org" <public-webcrypto@w3.org>, Harry Halpin <hhalpin@w3.org>, Wendy Seltzer <wseltzer@w3.org>
Message-ID: <076ED1F6CB375B4BB5CAE7873691360703902C604F4C@CROEXCFWP04.gemalto.com>
Thanks Ryan for the clarification,
Re-editing my "landscape". 
Regards,
Virginie
gemalto

Key operations :
Key generation - issue-19
Key exchange
Key import/export - raw material format is issue-14
Key usual operations (cipher, verify, .)
Key neutering - issue-8
Key cloning and sharing - issue-22
Generation of random value
Key query - basic search

Key Attributes/parameters :
origin - issue-19 (completed by issue-21)
Validity dates - semantic is issue-16
Local ID local
GUID - issue-25
User Attributes - user attributes access by application is issue-17
Certificate or generic tokens - issue-15
Algorithms
Algorithm type Usage
Extractable/Or not
Temporarily/Permanent


-----Original Message-----
From: Ryan Sleevi [mailto:sleevi@google.com] 
Sent: mardi 21 août 2012 19:38
To: GALINDO Virginie
Cc: public-webcrypto@w3.org; Harry Halpin; Wendy Seltzer
Subject: Re: [W3C Web Crypto WG] functional features list in draft API and issue tracker

On Tue, Aug 21, 2012 at 7:26 AM, GALINDO Virginie <Virginie.GALINDO@gemalto.com> wrote:
> Dear all,
>
>
>
> After Mark made the relevant comment about making sure functional 
> features are actually integrated in the API either by text or by 
> explicit issue, here is a summary of what I understand is in our API. 
> Thanks for completing/commenting this functional landscape if something missing.
>
>
>
> Key operations :
>
> Key generation - issue-19
>
> Key exchange
>
> Key import/export - raw material format is issue-14
>
> Key usual operations (cipher, verify, .)
>
> Key neutering - issue-8
>
> Key cloning and sharing - issue-22
>
> Generation of random value
>
> Key query - no description in API and no issue

Key Query is nominally supplanted by KeyStorage, which provides access to managing persisted keys that were generated by or imported by an origin for persistent storage, or pre-provisioned by a user agent that does such things.

The discussion of Key Query as a concept was related to origin authorization, from which discussion on the list, particularly from Netflix, expressed some concern and question over.

The broader question is whether there should also be a way to query for keys by arbitrary metadata. This has two shades - one, querying over existing keys (eg: keys in Key Storage), and two, as a means of discovering keys the user may already have (for example, in secure elements).

The latter seems to very much skew towards the smart card specific use case, hence it's lack of inclusion in the draft being put forward. The former is equally problematic, since it requires defining some sense of query syntax, which then requires agreement on an ontology and representation of key attributes, for which I think there is still a lot of confusion and/or disagreement on.

KeyQueryList the strawman [1] was modeled after MediaQueryList from the CSSOM View Module [2], but the syntax for queries was inherited from the Media Queries spec [3], which defined a common string representation. Trying to devise such a query syntax, in parallel to trying to define the API, is something that I fear would overload the already busy WG, hence why I avoided inserting the strawman. I still believe it's a useful discussion to have, but I'd suggest waiting until after we've made it through LC and seen adoption before we try to define what is True and Generic for all Keys.

As it stands, an application that wished to use application-specific symbolic identifiers could do so via a variety of ways.

/*
  Returns the key matching a particular name (eg: 'enc-key'),
  or null if the key does not exist.
*/
function /* Key */ getByName(/* string */ name) {
  for (int i = 0; i < window.crypto.keys.length; ++i) {
    var key = window.crypto.keys[i];
    if (window.localStorage.getItem('name.' + key.id) == name) {
      return key;
    }
  }
  return null
}

Applications can build increasingly more robust query languages atop this in order to match their needs. This is, to a degree, similar to the development history of CSS selectors, for which JavaScript libraries pushed the boundaries on.

The above example is just one example, and arguably the most inefficient but easiest to trivially demonstrate. An application can use any number of schemes to manage and query the attributes, and in most cases I believe it will be as trivial as a single object attribute lookup.

[1] http://lists.w3.org/Archives/Public/public-webcrypto/2012Jun/0047.html
[2] http://www.w3.org/TR/cssom-view/
[3] http://www.w3.org/TR/css3-mediaqueries/


>
> Management of Key Attributes - user attributes is issue-17
>
>
>
>
>
> Key Attributes/parameters :
>
> origin - issue-19 (completed by issue-21)
>
> Validity dates - semantic is issue-16
>
> Local ID local
>
> GUID - issue-25
>
> User Attributes - user attributes access by application is issue-17
>
> Certificate or generic tokens - issue-15
>
> Algorithms
>
> Algorithm type Usage
>
> Extractable/Or not
>
> Temporarily/Permanent
>
>
>
> In addition we have some design related issues (e.g. asynch versus 
> synchronous usage, or ), but I do not classify it as functional 
> feature issues as it is more a problem of choosing the best solution.
>
>
>
> Thanks for commenting.
>
>
>
> Regards,
>
> Virginie
>
> gemalto
>
> chair of Web Crypto WG

I
Received on Wednesday, 22 August 2012 14:38:36 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 22 August 2012 14:38:38 GMT