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 Tuesday, 21 August 2012 17:38:06 UTC