W3C home > Mailing lists > Public > public-web-security@w3.org > February 2015

Re: [WebCrypto.Next] "Plan B" - Chrome Native Messaging

From: Harry Halpin <hhalpin@w3.org>
Date: Thu, 05 Feb 2015 12:39:16 +0100
Message-ID: <54D35664.4090705@w3.org>
To: Ryan Sleevi <sleevi@google.com>, David Leon Gil <coruus@gmail.com>
CC: Billy Simon Chaves <b.simon@hermes-soft.com>, Anders Rundgren <anders.rundgren.net@gmail.com>, "public-web-security@w3.org" <public-web-security@w3.org>, "public-webcrypto-comments@w3.org" <public-webcrypto-comments@w3.org>, Siva Narendra <siva@tyfone.com>, Brad Hill <hillbrad@fb.com>, GALINDO Virginie <Virginie.Galindo@gemalto.com>, Lu HongQian Karen <karen.lu@gemalto.com>, Wendy Seltzer <wseltzer@w3.org>, POTONNIEE Olivier <Olivier.Potonniee@gemalto.com>, "PHoyer@hidglobal.com" <PHoyer@hidglobal.com>

On 02/05/2015 01:30 AM, Ryan Sleevi wrote:
> On Wed, Feb 4, 2015 at 4:11 PM, David Leon Gil <coruus@gmail.com> wrote:
>> So, a nit I have with WebCrypto/whatever at the moment, related to this issue.
>> If I want to make a webapp that stores unextractable keys, I can store
>> them in IndexedDB. A browser can implement IndexedDB by providing a
>> store that is, e.g., a Sqlite3 database on disk. With all of these
>> "unextractable" keys stored in plaintext.
> The spec is explicitly clear that this is a valid implementation
> strategy, although not required of implementors.
>> Every browser, however, does have an internal keystore
> False. No specification requires this of Web Browsers. What some
> browsers do (and again, not all of them do this) is not the same as
> all browsers.
>> (e.g., for
>> passwords). And (some of them) use the best available protection their
>> platform provides to protect entries in it.
> And that protection varies by platform to considerable extent, thus
> providing zero effective guarantees to a Web developer, short of
> coding platform-specific logic in the Web - which is, of course,
> exactly what the Web shouldn't do - or by requiring all platforms
> accessing the Web have some degree of restricted control capabilities
> that quickly borderlines on Trusted Computing.

While Ryan is right as regards the current lack of any kind of
consistent security properties of browser storage of keys, that seems
like a suitable topic for future exploration for possible
standardization. It's definitely a bug, not a feature, in my book
insofar as storing user's private material in plaintext on the client
side (and under server) control does likely violate the assumptions most
people I know have about cryptographic protocols.

>> I'd be happy if I could just store one entry in that keystore: A KEK
>> to wrap all of the keys when they're at rest.
>> But right now, as far as I know, I can't.
>> - dlg
> Correct. That is by design.
Received on Thursday, 5 February 2015 11:39:34 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 5 February 2015 11:39:35 UTC