W3C home > Mailing lists > Public > public-webcrypto@w3.org > April 2013

RE: Named key discovery questions

From: Vijay Bharadwaj <Vijay.Bharadwaj@microsoft.com>
Date: Thu, 25 Apr 2013 18:58:38 +0000
To: Ryan Sleevi <sleevi@google.com>
CC: Mark Watson <watsonm@netflix.com>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>
Message-ID: <8beb70c8f8334cbc8d2946db8013fef5@DFM-DB3MBX15-07.exchange.corp.microsoft.com>
You're right. I was forgetting that.

Mark, does this change the proposal?

-----Original Message-----
From: Ryan Sleevi [mailto:sleevi@google.com] 
Sent: Thursday, April 25, 2013 11:56 AM
To: Vijay Bharadwaj
Cc: Mark Watson; public-webcrypto@w3.org
Subject: Re: Named key discovery questions

On Thu, Apr 25, 2013 at 11:40 AM, Vijay Bharadwaj <Vijay.Bharadwaj@microsoft.com> wrote:
> 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.

We have the "type" attribute on the Key interface. What am I missing here?


> -----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
Received on Thursday, 25 April 2013 19:00:38 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:02:08 UTC