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

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 15:10:39 UTC