ISSUE-30: Key import/export?

Now, if we don't have key import/export, it seems to me it seems we're 
limiting ourselves to ephemeral keys generated in the JS by the same 
origin. Since we have no multi-origin policies and same-origin is the 
de-facto way to do this, I'm happy with that.

  In the spec now, there is just a place-holder:

"
15.2.8. The importKey method

15.2.9. The exportKey method"

  Nonetheless, I think a key import/export function might be useful. 
High-level libraries like Keyczar do key import/export, see their 
Encrypter method [1]. Could we do something similar and just lean on the 
File API to do the reading of keys [2], with a check to make sure the 
file is a valid bytestream or serialized JOSE key. That would also cause 
a dependency on the File API. Arun, when is the File API supposed to go 
to Rec?

The hard issue is how this interfaces with same-origin and privacy. Two 
thoughts:

Re privacy, I think we should say that if the key-material is a private 
key, moving it into structured clone localStorage/indexedDB should 
require a user prompt, and leave it to the implementer to define the 
security/privacy message to be stated.

Re same-origin, we could state that if the key is imported by explicit 
user selection (i.e. see privacy), then the key is treated as if it were 
generated by same-origin of the JS that called the File API to import 
the key. In export, we don't worry about it. Thus we don't have to deal 
with same origins. Thus we can still close ISSUE-19/ISSUE-26.

Before writing a WebIDL, I wanted a sanity-check on the thinking.

    cheers,
    harry

[1]http://www.keyczar.org/javadocs/index.html?org/keyczar/Encrypter.html
[2]http://www.w3.org/TR/FileAPI/

Received on Monday, 25 February 2013 20:44:58 UTC