Re: Key IDs take 2, plus public key as an (JWK) array buffer

----- Original Message -----
> From: "Ryan Sleevi" <sleevi@google.com>
> To: "David Dahl" <ddahl@mozilla.com>
> Cc: public-webcrypto@w3.org
> Sent: Wednesday, June 13, 2012 10:44:20 PM
> Subject: Re: Key IDs take 2, plus public key as an (JWK) array buffer

> Just a few questions to get the discussion started:
> 
>    - What's the imagined use case for boundOrigin?
I figured it was merely metadata that an application might use for display. The key is as described here would mainly be used to inform the authorized sites about the key's properties. 

>       - This attribute seems to very clearly disclose browsing habits
>       of
>       the user to multiple, un-related origins. What privacy
>       protections do you
>       imagine being implemented for this attribute?

I would think that sites not authorized at creation time would not ever know about the key or this ID.

>    - Is this a read-only property or a read-write property?
>       - Programatically from script?

read only - I was thinking the application would be handed the keyID on creation - along with the ArrayBuffer key object, but would only need to store the key id to effectively use the private side of the key pair. 

>       - Interactively by the user?
>    - If read-write, then if ["example.com"] attempts to add
>    ["evil.com"]
>    (eg: due to an XSS), what is the expected behaviour?
>       - For the user agent?
>          - Should ["evil.com"] be silently authorized?
>          - Is it acceptable for user agents to prompt the user?
>          - If so, what if the user declines?
>       - For the executing script?
>          - Can this operation fail?
>          - If the user agent needs to prompt, does it need to pause
>          the
>          current script while doing so? Or may it continue execution
> of the script?
>       - For the user?
>          - Can I restrict these uses in any way (eg: to avoid
>          super-cookies?)

I will think about these questions more in-depth, this is all a bit hand-wavy for sure as of yet:)

>       - You've effectively described a serialization format for the
>       public
>    key, interpreting it into an ArrayBuffer rather than JSON or some
>    other
>    form.
>       - Who or what is the intended consumer of the resulting
>       ArrayBuffer?
I was thinking the application that generates it may be using websockets and wants to push the key up to the server to share it without any additional encoding. I am not 100% percent sure this is a great use-case. I am working off of some initial ideas Adam Barth and Brian Smith had about the keys and most input and output being ArrayBuffers. 

>       - If a script needs to access the exponent, does this mean it
>       has to
>       deserialize what it obtained via the WebIDL?
>       - As noted in the JWK spec, it's a non-goal of the
>       specification to
>       represent private keys or symmetric keys. Considering that both
>       are very
>       much in-spec for our efforts, how do you see these being
>       represented?

I am not sure about symmetric keys (which I imagine we would only spec a wrapped format for). I think private keys will only ever be referred to via an ID, perhaps as a DOMString.

>    - It's not clear the interaction between key ID, key "handle",
>    ArrayBuffers, and JWK. Could you demonstrate a code snippet with
>    how a
>    developer might use your proposal to:
>       - Locate a key with a given ID (previously generated)
>       - Generate a new key (with or without specifying some ID?)
>       - Execute some hypothetical key exchange algorithm "Foo", which
>       yields a third key.
>       - Remember/store this third key for future visits to this web
>       site
>          - On the client (localStorage?)
>          - On the server (some serialization form that doesn't
>          disclose the
>          /contents/ of the key)
> 

I have begun to work out some more code examples in this vein. I will post them soon. Again, these are hand-wavey ideas I have been working out on paper to gather some initial feedback.

> I realize that much of the example I ask relates to API, so please
> feel
> free to be hand-wavey without commiting to any functions/behaviours,
> I'm
> just trying to get a picture of where/when an application might need
> to
> access the properties/values you're proposing (either for key id or
> for the
> JS object literal), and how they might do so. If you have a better
> example
> workflow, fantastic, please use that instead.
> 

Thanks for your quick feedback. More soon.

Regards,

David

Received on Thursday, 14 June 2012 04:04:04 UTC