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

Named key discovery questions

From: Mark Watson <watsonm@netflix.com>
Date: Thu, 25 Apr 2013 10:06:18 -0700
Message-ID: <CAEnTvdADaybWyPcQ-aA5xA-yiyOn55cxYMFzUHkt-zR_ZCG53A@mail.gmail.com>
To: public-webcrypto@w3.org

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 ?


Received on Thursday, 25 April 2013 17:06:55 UTC

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