Re: Scope of key discovery draft

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" :)

Received on Tuesday, 11 December 2012 01:08:56 UTC