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

Sure,

Its RFC 5705. [1]

Cheers,
S

[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