Re: [Web Crypto Next] Lets start discussing !

Dear Anders -- I totally agree...Nothing is pretty right now! And FIDO as
one size fits all prescription is worrisome. FIDO is a solution, an
important one. But it is not the only solution. As long as we can define a
path where multiple of these protocols can coexist that would be ideal.

Best,
Siva



*--*


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


On Wed, Oct 29, 2014 at 9:06 PM, Anders Rundgren <
anders.rundgren.net@gmail.com> wrote:

> Hi Siva,
>
> As seen from the messages on this list we are not anywhere near consensus
> on what to do so the best I can do is elaborating a bit on my conclusions
> which are both based on facts and on observations
>
> One reason why simply bolting NSS et. al. to the web wasn't considered is
> because NSS wasn't designed to be called by arbitrary, potentially
> malicious, transiently downloaded web-code.  The same is valid for
> EMV-cards which are to be used in specific terminals equipped with
> certified software.
>
> FIDO's U2F addresses this problem in a novel way which though requires new
> middlware, hardware and browser upgrades.
>
> The problem (that we agree on), is that U2F (in its current incarnation)
> is not a replacement for existing smart cards.
>
> Various solutions have indeed been suggested but since these have all been
> dismissed/ignored by the browser vendors, it is really up to the browser
> vendors stating their take on the matter.
>
> The Swedish banks have after the removal of browser plugin support
> replaced their web-based PKI-solution with iOS and Android apps. It is not
> pretty but it is better than nothing :-)
>
> Sincerely,
> Anders Rundgren
>
> On 2014-10-30 03:28, Siva Narendra wrote:
>
>> 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 | Taipei/
>> www.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 <mailto: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
>>
>>
>>
>>
>>
>