Re: [W3C WebCrypto API WG] Key discovery

On Thu, Apr 4, 2013 at 5:37 PM, Mountie Lee <mountie@paygate.net> wrote:
> 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.

There is no planned overlap at this time.

We intentionally plan to ignore the existing storage for the many
security and privacy reasons that have been discussed in the past on
the list.

They are vastly different security scenarios.

>
> 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
>

Received on Friday, 5 April 2013 01:02:21 UTC