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

On 9 Dec 2011, at 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:-)

+1 

I think there is good reason to work with X509 Access, because it would allow
the same keys to work at the https layer with WebID ( https://webid.info/spec )
and with BrowserId . 

> 
> - 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.
>> 
>> 
> 

Social Web Architect
http://bblfish.net/

Received on Friday, 9 December 2011 14:42:46 UTC