Exposing non-exportable key material (was Re: Scope of key discovery draft)

On Dec 10, 2012, at 5:01 PM, Ryan Sleevi wrote:

> On Mon, Dec 10, 2012 at 4:37 PM, Mark Watson <watsonm@netflix.com> wrote:
>> 
>> Sure, but my point is just that if "exportable = false" is to mean anything it has to mean that the implementor has taken *some* care to make it non-trivial to for scripts to get the key.
>> 
>> For example, if an implementation also provided a method like this:
>> 
>> ArrayBufferView Window.secretGetWebCryptoNonExportableKey( Key theKey )
>> 
>> then I think we would say that the "exportable=false" setting is a little meaningless on that platform.
>> 
>> Now, there is (hopefully) no need to provide any guidance that says implementations should not implement a method like the above one.
>> 
>> However, leaving gaping security holes in an IndexedDB implementation, such that retrieving keying material for non-exportable keys is trivial, is essentially the same thing as proving the above method. Some guidance on this might be in order: users of the API expect that storing keys in IndexedDB won't make access to non-exportable keying material any easier than it was before.
>> 
> 
> My motto has long been "You can't have a spec prevent stupid"
> 
> I agree in that everything you say is "common sense" and exactly how
> it "should" be. But I don't know if the spec can provide any guarantee
> that implementations "won't be stupid" or "won't make mistakes", and
> so for a web developer/author, it's not really a guarantee.
> 
> That said, I have no objection to the politically balanced,
> non-hostile textual equivalent of "Implementors: Don't be stupid. Use
> common sense" :)
> 

I'm suggesting a normative requirement, if we don't have it already, that "the UA SHALL NOT expose key material to scripts for keys where exportable = false". Do you disagree with that ? (it appears you did, earlier in the thread, but I'm not sure if you really meant to).

Given that, this conversation started with the suggestion that some guidance was needed to re-assure users that the above remains true when a Key is placed into IndexedDB. Similarly, guidance for UA implementors that their implementation of Keys-in-IndexedDB should not break the above requirement.

This may be obvious, though the existence of this thread is evidence against that ;-)

For example, the implementor of the Key object and the internal code that makes that object storable in IndexedDB may not be aware of all the security properties of IndexedDB. This would be a flag to ensure that they talk to their IndexedDB security people to ensure that the SHALL NOT above remains just as true when the Key is in IndexedDB.

…Mark

Received on Tuesday, 11 December 2012 19:44:11 UTC