Re: [W3C WebCrypto API WG] Key discovery

My comment for key discovery is
keeping existing TLS Client Key Storage and it's discovery rules.
that will give backward compatibility and match user expectations.

I don't know how much the TLS Client Key Storage is different from current
webcrypto's keystorage internally.
but we can not ignore existings.

regards
mountie.


On Fri, Apr 5, 2013 at 9:25 AM, Mark Watson <watsonm@netflix.com> wrote:

> Scope issues aside, on the technical side it's difficult to see how this
> could be interoperable without further specification.
>
> Considering the use-case given, there would need to be a specification
> (somewhere) of the format of the Government-issued certificate which
> included details of how the various properties of that certificate were
> handled by the ( attribute name, value ) filter matching (i.e. what are the
> attribute names and how are their values derived from the certificate and
> how is the matching done), how the Issuer and isPrivate should be set and
> what kind of authentication was required.
>
> UA's could then know how to support that kind of certificate and
> applications would know what to look for.
>
> Typically in these kind of situations we have a chicken-and-egg problem.
> There is reluctance to specify a lookup capability in WebCrypto when we
> have no idea what kinds of things we're trying to look up. On the other
> hand, noone is going to write a "how to expose XYZ key in WebCrypto"
> specification if there is obviously no method in WebCrypto to do that.
>
> One way to resolve that problem is to signal intent with a simple API and
> define a registry for specifications that define how it is used. For
> example, if the getKeys() call included a "type" parameter, with a registry
> for type values, then implementors would know that to implement getKeys()
> they just have to look through the registry, get the specifications
> registered there and implement zero or more of those. There's no
> requirement to implement any of them.
>
> Typically, W3C has preferred people to come to W3C itself and write those
> specifications here. That has the advantage that the specifications fall
> under the W3C patent policy. The W3C has deviated from this only when it
> has been practically impossible. MIME types for media codecs would be an
> example of a type field with a registry operating in very much the way I
> described.
>
> However, the scope quoted by Ryan does seem to rule out that approach in
> the short term ...
>
> ...Mark
>
>
>
> On Thu, Apr 4, 2013 at 4:37 PM, Ryan Sleevi <sleevi@google.com> wrote:
>
>> Issuer is underspecified, and as such, not possible to implement.
>>
>> Further, this seems to directly conflict with the charter, which states:
>>
>> "Out of scope: features including special handling directly for
>> non-opaque key identification schemes, access-control mechanisms
>> beyond the enforcement of the same-origin policy, and functions in the
>> API that require smartcard or other device-specific behavior"
>>
>> This requires both handling for non-opaque key identification scheme
>> ("issuer") as well as an access control mechanism ("isPrivate")
>>
>> As such, we do not support the WG taking on this item.
>>
>> On Thu, Apr 4, 2013 at 4:21 PM, Lu HongQian Karen <karen.lu@gemalto.com>
>> wrote:
>> > Hi Mark,
>> >
>> > We would like to suggest expanding the key discovery specification by
>> adding an API for discovering pre-provisioned cryptographic keys via any of
>> their attributes. This gives web applications a mean to find
>> pre-provisioned keys whose names are unknown to them.
>> >
>> > The contribution is attached for review.
>> >
>> > Regards,
>> > Karen and Michael
>> >
>> >
>>
>
>


-- 
Mountie Lee

PayGate
CTO, CISSP
Tel : +82 2 2140 2700
E-Mail : mountie@paygate.net

=======================================
PayGate Inc.
THE STANDARD FOR ONLINE PAYMENT
for Korea, Japan, China, and the World