Re: Named key discovery questions

On Thu, Apr 25, 2013 at 1:10 PM, Acar, Tolga <tolga.acar@intel.com> wrote:

>  This is a stretch, but I’ll say it anyhow.****
>
> ** **
>
> In a multi-party key exchange (think [EC]DH with >2 parties), the public
> keys a recipient receives from other parties may have the same name (this
> is the stretch part), but the public key values are different with
> overwhelming probability. They are different key objects with different key
> values.
>

Here we are considering named pre-provisioned keys. Are you imagining an
online provisioning system where the keys are provisioned using a
multi-party key exchange ? I'm not sure what the "names" associated with
the public keys in that key exchange are or whether they need to be the
same as the names we are considering here, which would be names for the
agreed keys.

Let me contrive an example: suppose a handheld device has some kind of
social network woven deeply into its operating system and the OS provides a
way to get shared key for a subset of the user's friends. A UA decides to
expose this OS capability to web pages through WebCrypto. Let's assume it
exposes a way to discover and communicate with the friends too, so that the
keys might possibly be useful to the web page.

So, the UA decides that these keys will appear as named origin-specific
pre-provisioned keys. The name in this case need to identify a subset of
the friends, who will then take part in a multi-party key exchange
(assuming the user approves this).

Well, I said the example was contrived. Does it illustrate the point,
though ?

...Mark


> ****
>
> ** **
>
> **-          **Tolga****
>
> ** **
>
> *From:* Mark Watson [mailto:watsonm@netflix.com]
> *Sent:* Thursday, April 25, 2013 12:01 PM
> *To:* Hutchinson Michael
> *Cc:* Vijay Bharadwaj; Ryan Sleevi; public-webcrypto@w3.org
>
> *Subject:* Re: Named key discovery questions****
>
>  ** **
>
> Doh! My bad. I completely blanked on that.****
>
> ** **
>
> So, good, we can tell public and private.****
>
> ** **
>
> Nevertheless, I'm still in search of any motivation for having more than
> one key with the same name.****
>
> ** **
>
> ...Mark****
>
> On Thu, Apr 25, 2013 at 11:57 AM, Hutchinson Michael <
> Michael.Hutchinson@gemalto.com> wrote:****
>
> Why can't you tell from the type?
>
> enum KeyType {
>   "secret",
>   "public",
>   "private"
> };
>
> readonly attribute KeyType type;
>
> >Michael****
>
>
> -----Original Message-----
> From: Vijay Bharadwaj [mailto:Vijay.Bharadwaj@microsoft.com]
> Sent: Thursday, April 25, 2013 1:41 PM
> To: Ryan Sleevi; Mark Watson
> Cc: public-webcrypto@w3.org****
>
> Subject: RE: Named key discovery questions
>
> I don't have a strong opinion on this specific issue, but it does strike
> me as a problem that within our API public keys and private keys would be
> indistinguishable from each other. Wouldn't you be able to tell the
> difference from the usages? (since public keys can only have one or more of
> verify, encrypt and wrap, while private keys must pick from sign, decrypt
> and unwrap)
>
> If the above were true, and we want to accommodate the case of keys pairs
> with the same names, we could also say that keys with the same name must
> have different usages.
>
> -----Original Message-----
> From: Ryan Sleevi [mailto:sleevi@google.com]
> Sent: Thursday, April 25, 2013 10:10 AM
> To: Mark Watson
> Cc: public-webcrypto@w3.org
> Subject: Re: Named key discovery questions
>
> On Thu, Apr 25, 2013 at 10:06 AM, Mark Watson <watsonm@netflix.com> wrote:
> > All,
> >
> > At the meeting yesterday there were two questions regarding named key
> > discovery for the Key Discovery draft.
> >
> > First, how are public/private key pairs handled. Second can more than
> > one key have the same name.
> >
> > I checked the main draft and AFAICT there is no way to distinguish a
> > public key from a private key by looking at the Key object. You have
> > to know a priori. In the named key discovery context, this means such
> > keys would need to have different names.
> >
> > Regarding multiple keys with the same name, the API supports this now
> > and the implication would be that you would then examine the Key
> > objects to determine which was which. If two indistinguishable keys
> > are returned the app has no way to decide - or even to ask the user -
> > which to use. This implies that keys with the same name must differ in
> > some other detectable way. That seems a rather awkward and error-prone
> > restriction. Especially since one of the most obvious cases for
> > grouping keys under the same name - the public private key case -
> > wouldn't be supported because this difference is not detectable.
> >
> > Given the above, I'm inclined to propose that we make the API as
> > simple as possible whilst still supporting the use-cases. With the
> > present use-cases, that would mean requiring that every key have a
> > distinct name and modifying the API to return NamedKey? instead of
> NamedKey[].
>
> +1
>
> >
> > Does anyone have use-cases for named keys that would not be supported
> > if we make this change ? Can you provide details ?
> >
> > Thanks,
> >
> > Mark
>
> ****
>
> ** **
>