W3C home > Mailing lists > Public > public-identity@w3.org > December 2011

Re: Key Opacity/Identification Issue - Web Cryptography Charter Updated

From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Date: Fri, 09 Dec 2011 16:41:59 +0000
Message-ID: <4EE23A57.2080205@cs.tcd.ie>
To: Anders Rundgren <anders.rundgren@telia.com>
CC: Harry Halpin <hhalpin@w3.org>, "public-identity@w3.org" <public-identity@w3.org>


Its RFC 5705. [1]


[1] http://tools.ietf.org/html/rfc5705

On 12/09/2011 03:09 PM, Anders Rundgren wrote:
> Stephen,
> Would it be asking too much for an overview of what you mean with TLS
> key extraction and what you can do with it?
> Note, this is not criticism, it is only pure curiosity&  ignorance :-)
> Anders
> On 2011-12-09 14:29, Stephen Farrell wrote:
>> - I'd still prefer TLS key extraction as primary. IMO it is a mistake
>> to ignore what's there already (the TLS protocol) and encourage web
>> application developers to badly re-invent that, which is what the
>> current charter does. (But I've said that 3 times now and it hasn't
>> been taken on board so I guess we're all just doomed:-)
>> - To be clear: I'd prefer see this WG succeed with this (currently
>> broken in the above way) charter than delay more or not have it
>> happen at all.
>> - "prevent external access" seems wrong, both because you can't really
>> for sure, and because downloaded code using a key is arguably a form of
>> external access so s/prevent external access/control access/
>> I'd also add "other sensitive cryptographic values and settings" after
>> "secret key material" since with a generic crypto API (as this is)
>> its likely that more than just secrets will be sensitive. Can't
>> recall if that phrase was in the earlier versions, sorry for not
>> catching it earlier if it was.
>> S
>> On 12/09/2011 12:32 PM, Harry Halpin wrote:
>>> I've updated the Web Cryptography Charter based on feedback from various
>>> people, both in and off list. The new version is here:
>>> http://www.w3.org/2011/11/webcryptography-charter.html
>>> I'd like in particular to point out that one of the most issues has the
>>> been the keys having "opaque" identifiers. In this, I'd like to clarify
>>> that the keys be opaque *to the API*.
>>> If a key is pre-provisioned in the key-store of the browser or if the
>>> key generation is done outside (say pre-provisioned a USB key) and then
>>> somehow "imported" into the keystore, the API should maintain whatever
>>> identification scheme that belonged to the key when it was first minted.
>>> However, making the code connecting preprovisioned keys with particular
>>> identification schemes will not be the responsibility of the
>>> implementers of the API, but will rest will whoever wants to provision
>>> the keys.
>>> By saying "opaque", I only mean that there should be *no* special key
>>> identification schemes natively promoted or understood by the API and no
>>> special routines for handling that. So for the API the identification
>>> scheme is opaque, but it can be non-opaque as the key-related
>>> information is handled "downstream" by the application.
>>> Thus I have "specification in API of special handling for non-opaque key
>>> identifiers" as out of scope. Also we have moved "information about the
>>> destination and provenance of a key beyond the enforcement of the
>>> same-origin policy" back into out of scope.
Received on Friday, 9 December 2011 16:42:37 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:00:47 UTC