Re: [Web Crypto Next] Lets start discussing !

Dear Anders --

Some clarifications:

   1. Apple Pay with Apple Watch will work on older iPhones as well as
   iPhone 6.

   2. Let us not confuse smart card plastic with smart card chips. Just
   because smart card plastic cannot be plugged into a PC/client device
   doesn't means smart cards cannot be through USB, BLE, or NFC.

   3. It is not that smart cards (chips) are not designed for the web. Web
   browsers (other than Firefox and to some extent IE) are not designed to
   easily integrate to the smart card (chips). If all of the browsers
   implemented NSS, smart cards will work out of the box with them. There are
   other alternatives, but the standardization that is missing is on the
   browser side. Not on the smart card side. FIDO is one possible solution,
   but has virtually zero penetration. And I do not know of a single company
   that would bet the farm only on FIDO. Globally there are lot more smart
   card (plastic and chips) what work with the web as opposed to FIDO devices.
   In fact from what I understand FIDO devices will also use smart card chips.

-Siva


*--*


*Siva G. Narendra Ph.D. CEO - Tyfone, Inc.Portland | Bangalore |
Taipeiwww.tyfone.com <http://www.tyfone.com>*
*Voice: +1.661.412.2233*


On Tue, Oct 28, 2014 at 11:48 PM, Anders Rundgren <
anders.rundgren.net@gmail.com> wrote:

> Apple didn't try to retrofit the old devices when they created Apple Pay.
>
> Although there are business models involved as well, Apple would also
> have created huge problems for banks (and users) if everybody have
> had to implement (and use) a "fallback" solution as well.
>
> I.e. you should IMHO not expect PKCS #11 and existing smart cards to become
> a part of the plot because they were simply put not designed for the web.
>
> Regards
> Anders Rundgren
>
> On 2014-10-28 09:09, helpcrypto helpcrypto wrote:
>
>> Hi
>>
>>
>> Don't know if I'm late, but as nvdbleek proposed [1], we are truly
>> interested in a web-document signing approach.
>>
>> Actually we suffer Java applets, and dream about a Javascript alternative
>> (like Webcrypto) but with the possibility of looking for an specific key
>> (even at specific card).
>>
>> So, something like findCertificate(token,filter) where filter can be
>> subject, issuer or a combination of them would be great.
>>
>> Regarding to population, we have several smartcards from different
>> manufacturers which -sadly- use different PKCS#11, so
>> generateKey(token,keyinfo) could also be interesting.
>>
>> Finally, we do batch signing, where one PIN let the user sign a batch of
>> documents (currently hashes), so this feature is also very interesting.
>>
>>
>> With these constraints in mind, we propose -more or less- the following
>> API:
>>
>>   - optional getToken to retrieve a token handle to work with. This could
>> be also issues to secure communications between server and client, using SM
>> and/or component certificates like some eID.
>>   - getCertificate(filter) which can allow us to filter and show a
>> "filtered dialog". some exaples: fingerprint, issuer, subject,
>> keyUsage...using a json-like filter which allows combination seems to be
>> much better.
>>
>> Signatures are made in 3 steps:
>>   - init: needed initialization
>>   - add: invoked for each document we want to sign. the document is sent
>> to the component/browser and stored internally
>>   - final: a final "you are going to sign this" dialog is shown. It will
>> be possible to even show a preview of the documents (pdf,xml+xslt,...)
>> using other plugins. asks for pin
>>
>> Of course, all this must be Js asynchronous
>>
>> We usually do XAdES or PAdES signing. probably a signed js library or
>> something lika that could be great to extend usage.
>>
>>
>> This is what actually our applet does, and its the use case we would live
>> to have on Webcrypto.
>>
>> Don't hesitate to contact me if you want to discuss this in deep.
>> Regards
>>
>>
>> [1] http://www.w3.org/2012/webcrypto/webcrypto-next-
>> workshop/papers/Using_the_W3C_WebCrypto_API_for_Document_Signing.html
>>
>>
>
>