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

Re: Named key discovery questions

From: Ryan Sleevi <sleevi@google.com>
Date: Thu, 25 Apr 2013 10:09:50 -0700
Message-ID: <CACvaWvZwwrbGhVxfDKATF4uJ4D4ynggjEh4ZgR52m=8jPBeBXA@mail.gmail.com>
To: Mark Watson <watsonm@netflix.com>
Cc: "public-webcrypto@w3.org" <public-webcrypto@w3.org>
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[].


> 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 17:10:21 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:16 UTC