Re: Named key discovery questions

On Thu, Apr 25, 2013 at 2:55 PM, Ryan Sleevi <sleevi@google.com> wrote:

> On Thu, Apr 25, 2013 at 2:34 PM, Richard Barnes <rbarnes@bbn.com> wrote:
> > If we can agree that key names are unique, can we simplify the API to
> just return a dictionary of Keys, indexed by name?  I've been kind of
> baffled by the fact that the app has to know the name a priori.
> >
> > --Richard
>
> The current API allows much richer implementations and use cases.
>
> The easiest example is a device that has a single/set of device
> specific key, and from that, derives origin-specific keys. Further,
> there may be multiple keys derived from this master key - think of
> this akin to the label parameter of a KDF.
>
> With getKeyByName(DOMString), the application can defer instantiation
> of this KDF/derivation of this material until a UA actually requests
> it. For example, it may allow ARBITRARY DOMStrings, to be treated
> literally as the 'label' for a KDF in concatenation with the origin.
>
> A get[All]Keys() API like you propose could not accomplish this by
> itself. It would need some set of supplementary methods.
>
> Finally, the experience of Web APIs is that a design that requires all
> possible elements and having an application filter them are worse for
> performance and usability than specific API(s) that match on narrower
> criteria.
>
> And regardless of the "Wouldn't it be nice if", I agree with Mark's
> sentiments that concrete use cases need to inform this, and there
> haven't been any provided that show where getKeyByName()
>
> So a strong -1 to returning a dictionary.
>

I agree with your points, but I'm intrigued by this new kind of math where
the integer -1 has multiple values, some "strong" some not. Do the strong
integers help the weak ones, or do they just rule over them ? Is it like
the strong and weak nuclear forces, or something else ? ;-)


>
> >
> >
> >
> > On Apr 25, 2013, at 3:00 PM, Mark Watson <watsonm@netflix.com> wrote:
> >
> >> 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
> >>
> >>
> >>
> >
>