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

On Wed, Jun 13, 2012 at 8:23 PM, David Dahl <ddahl@mozilla.com> wrote:

> Hello All:
>
> I updated the key ids idea on my github, mixing in Ryan's object concept:
> https://github.com/daviddahl/web-crypto-ideas/commit/d0386c76a2c09e69203cfb6ac2476ef1c3588a44
>
> In short:
>
> window.crypto.sym.algorithms.blockenc;
>
> ( instead of )
> // returns array of strings: ["A128CBC", "A256CBC", "A128GCM","A256GCM"]
>
> ( we have )
> // returns an object:
> { A128CBC: true, A256CBC: true, A128GCM: false, A256GCM: false }
>
> Also, I took a stab at key identifiers and  representing a public key as a
> JWK as an ArrayBuffer:
>
> https://github.com/daviddahl/web-crypto-ideas/blob/master/key-ids.js
>
> In short:
>
> Key ID:
>
> {
>  algorithm: "RSA1_5",
>  id: "8d88ef7e-3e51-4776-b017-340ba04c954",
>  // browsers can create any kind of string ID,
>  // perhaps 'mozilla.org/key-234456789.jwk' as well
>  boundOrigin: ["w3.org", "mozilla.org"],
> }
>
> And, a public key as ArrayBuffer:
>
> // JS object literal:
> {
>  alg: 1, // 1 = RSA, char: 49
>  kid: "https://mozilla.com/key-1234567890.jwk",
>  // char:
> 104,116,116,112,115,58,47,47,109,111,122,105,108,108,97,46,99,111,109,47,107,101,121,45,49,50,51,52,53,54,55,56,57,48,46,106,119,107
>  use: 1, // 1 = enc, char: 49
>  boundOrigin: "mozilla.com,w3.org", // Not an IETF/Jose property
>  // char: 109,111,122,105,108,108,97,46,99,111,109,44,119,51,46,111,114,103
>  mod: 1234567, // char: 49,50,51,52,53,54,55
>  exp: 1, // char: 49
> }
>
> // Imagine the Array buffer's data as:
>
>
> [49,104,116,116,112,115,58,47,47,109,111,122,105,108,108,97,46,99,111,109,47,107,101,121,45,49,50,51,52,53,54,55,56,57,48,46,106,119,107,49,109,111,122,105,108,108,97,46,99,111,109,44,119,51,46,111,114,103,49,50,51,52,53,54,55,49]
>
> // With header data prepended to the above:
> [1,38,1,18,7,1]
> // Which is the length of each property
>
> // Naturally, DSA and EC keys would have some differing properties as per:
> http://tools.ietf.org/html/draft-ietf-jose-json-web-key-02
>
> // Following naturally, perhaps there is a need for a utility method to
> convert this ArrayBuffer public key to JSON?
>
> var jsonKey = myPublicKey.toJSON();
> //returns a JWK object with base64 UrlEncoded properties, etc...
>
> Regards,
>
> David
>
>
Hi David,

Just a few questions to get the discussion started:

   - What's the imagined use case for boundOrigin?
      - 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?
   - Is this a read-only property or a read-write property?
      - Programatically from script?
      - 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?)
      - 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?
      - 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?
   - 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 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.

Cheers,
Ryan