Re: [W3C WebCrypto API WG] Key discovery

Hi Nick,

Apparently I missed the wiki for the use case, now, since there are 
different proposals with different use cases/ideas being written 
currently, the idea maybe is to adopt the same conventions (like the 
CertificateOperation interface if everybody agree, and certificate 
discovery should probably follow the same rules as key discovery since 
the job has been done already ) and then at the end everything can be 
merged together and/or interoperate.

Regards,

Le 08/04/2013 18:51, Nick Van den Bleeken a écrit :
> Thank you Aymeric,
>
> My answer is inline.
>
> On 8 apr. 2013, at 17:45, "America Vitte" <vitteaymeric@gmail.com 
> <mailto:vitteaymeric@gmail.com>> wrote:
>
>> Maybe I am misreading but looking at the API and test.html it seems 
>> to be more related to a certificate discovery proposal rather than a 
>> key-certificate-discovery one (in your example result is an array of 
>> certificates).
> It's about discovering certificates and their associated keys based on 
> certificate properties.
>>
>> And then I don't really understand why for example 
>> |X509CertificateSelector is a KeyOperation and not something like a 
>> CertificateOperation (like in [1] for example) implementing 
>> EventTarget (which you don't really use in your examples, and|||'<li 
>> class="ui-widget-content">' + certificates[i] + '</li>'|looks 
>> strange...), and then certificates discovery should follow the same 
>> SOP rules as key discovery.
>> |
> I will incorporate your comments. And add some more documentation 
> (there is a related paper about this work, but that one is not yet 
> public because it is submitted for WASH13).
> The available certificates will be configurable by the end user on a 
> per site basis (using a subtle UI, something like is done for the 
> location, webRTC, ...)
>> |
>> That's not critics but comments, probably it's as start as you 
>> mentioned, for your test your extract certificates and then sign them 
>> if I understand correctly, maybe you should add the use case in the 
>> proposal.
>> |
> There is already one use case documented(Document signing).
> Will add some more.
> https://github.com/InventiveDesigners/webcrypto-key-certificate-discovery-js/wiki/UseCases
>> |
>> Regards,
>>
>> [1] https://gist.github.com/Ayms/d21bbab05361bd58c439
>> |
>
> Thank you for your constructive comments.
>> |
>>
>> |
>> Le 08/04/2013 12:12, Nick Van den Bleeken a écrit :
>>> Hi Mark,
>>>
>>> You might want to have a look at [1].
>>>
>>> I and a colleague of mine are working on a proposal for a key 
>>> discovery API using its associated X509 certificate. We are still in 
>>> an early phase, but started prototyping the API as native browser 
>>> extension. The API description[2] and code of the prototype is 
>>> available at github at [1].
>>>
>>> We started this project in the hope to keep the discussion about 
>>> getting access to smart cards and USB security tokens on the web 
>>> active. And possibly use it as starting point for a proposal for a 
>>> key/discovery API to the WG.
>>>
>>> Kind regards,
>>>
>>> Nick Van den Bleeken
>>> 1: 
>>> https://github.com/InventiveDesigners/webcrypto-key-certificate-discovery-js
>>> 2: 
>>> https://github.com/InventiveDesigners/webcrypto-key-certificate-discovery-js/wiki/API 
>>>
>>>
>>> On 05 Apr 2013, at 02:25, Mark Watson <watsonm@netflix.com 
>>> <mailto:watsonm@netflix.com>> wrote:
>>>
>>>> Scope issues aside, on the technical side it's difficult to see h
>>>> ow 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 
>>>> <mailto: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 <mailto: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
>>>>     >
>>>>     >
>>>>
>>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> Inventive Designers' Email Disclaimer:
>>> http://www.inventivedesigners.com/email-disclaimer
>>
>> -- 
>> jCore
>> Email :avitte@jcore.fr
>> iAnonym :http://www.ianonym.com
>> node-Tor :https://www.github.com/Ayms/node-Tor
>> GitHub :https://www.github.com/Ayms
>> Web :www.jcore.fr
>> Webble :www.webble.it
>> Extract Widget Mobile :www.extractwidget.com
>> BlimpMe! :www.blimpme.com
>
> ------------------------------------------------------------------------
>
> Inventive Designers' Email Disclaimer:
> http://www.inventivedesigners.com/email-disclaimer

-- 
jCore
Email :  avitte@jcore.fr
iAnonym : http://www.ianonym.com
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
Web :    www.jcore.fr
Webble : www.webble.it
Extract Widget Mobile : www.extractwidget.com
BlimpMe! : www.blimpme.com