RE: Named key discovery questions

Concrete example:

KeyPair "Netflix Samsung 1"
KeyPair.publicKey "Netflix Samsung 1"
KeyPair.privateKey "Netflix Samsung 1"

So for the case where GetKeysByName is looking for a private key from a key pair you would pass in "Netflix Samsung 1" and get back an array of NamedKey; iterating over these keys by type to find the private one.
Iteration is needed as NamedKey inherits from Key and not KeyPair.

KeyPair "Netflix Samsung 1"
KeyPair.publicKey "Netflix Samsung 1 Public"
KeyPair.privateKey "Netflix Samsung 1 Private"

So for the case where GetKeysByName is looking for a private key from a key pair you would pass in "Netflix Samsung 1 Private" and get back just one NamedKey - the private one.

But as the name here are arbitrary; as there is no specification for the naming convention yet and there may never be...it could equally be

KeyPair "Netflix Samsung 1"
KeyPair.publicKey "Netflix Samsung 1 Private"
KeyPair.privateKey "Netflix Samsung 1 Public"

So for the case where GetKeysByName is looking for a private key from a key pair you would pass in "Netflix Samsung 1 Public" and get back just one NamedKey - the private one.

As long as the Web App knows the unique name of the key it is looking for there should be no need to return an array.

But it comes down to how the names are generated and passed to the Web App that uses them...which is out of scope?

>Michael

P.S. The KeyPair name is notional as there is no NamedKeyPair.


From: Mark Watson [mailto:watsonm@netflix.com]
Sent: Thursday, April 25, 2013 5:03 PM
To: Ryan Sleevi
Cc: Richard Barnes; Hutchinson Michael; Vijay Bharadwaj; public-webcrypto@w3.org
Subject: Re: Named key discovery questions


On Thu, Apr 25, 2013 at 2:55 PM, Ryan Sleevi <sleevi@google.com<mailto:sleevi@google.com>> wrote:
On Thu, Apr 25, 2013 at 2:34 PM, Richard Barnes <rbarnes@bbn.com<mailto: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<mailto: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<mailto: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<mailto:Vijay.Bharadwaj@microsoft.com>]
>> Sent: Thursday, April 25, 2013 1:41 PM
>> To: Ryan Sleevi; Mark Watson
>> Cc: public-webcrypto@w3.org<mailto: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<mailto:sleevi@google.com>]
>> Sent: Thursday, April 25, 2013 10:10 AM
>> To: Mark Watson
>> Cc: public-webcrypto@w3.org<mailto:public-webcrypto@w3.org>
>> Subject: Re: Named key discovery questions
>>
>> On Thu, Apr 25, 2013 at 10:06 AM, Mark Watson <watsonm@netflix.com<mailto: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
>>
>>
>>
>