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

Sorry about reviving this old thread - I was slammed the last couple of weeks and I'm just catching up with my email backlog.

I echo Ryan's concerns here. I'm not sure why boundOrigin needs to be exposed to applications at all. It (or something like it) needs to be maintained by the user agent, but it seems to me that such privacy-impacting metadata is conceptually at a higher confidentiality level than any app.

You make a good point about the need for some metadata that can be used as a "friendly name" for the key in various UI contexts. However, I wonder if we should be depending on the app to display such metadata correctly, especially given the discussion about an app accessing keys created outside the app. Perhaps it would be better to have a model where such metadata can be written at key creation time and later used by apps for key selection, but is displayed by the user agent?

-----Original Message-----
From: David Dahl [mailto:ddahl@mozilla.com] 
Sent: Wednesday, June 13, 2012 9:04 PM
To: Ryan Sleevi
Cc: public-webcrypto@w3.org
Subject: 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 Saturday, 30 June 2012 07:11:37 UTC