RE: [Web Crypto Next] FIDO - Lets start discussing !

Thanks Anders

I will have a chat with Jan-Erik

Regards

Don


From: Anders Rundgren [mailto:anders.rundgren.net@gmail.com]
Sent: 03 November 2014 20:47
To: Don Felton
Cc: public-web-security@w3.org
Subject: Re: [Web Crypto Next] FIDO - Lets start discussing !

On 2014-11-03 19:19, Don Felton wrote:
Hi Andres
Hi Don,



>FWIW, I am personally only interested in extending the WebCrypto API and Architecture to do things which FIDO does not.


I think we all support that level of flexibility. I assume that’s why we don’t want blind NSS exposure.

"we don't want to blind NSS exposure"  I'm not entirely sure what that means but I certainly don't want to see any traces of NSS in this context :-)



But I am afraid you have lost me here….

> However, I would "borrow" one key characteristic of FIDO's U2F and that is creating new and for the purpose specifically designed hardware security technology rather than spending EONs of time pushing square pegs into round holes.

Which purpose and which hardware security technology?

U2F defines a new token with a specific (fixed) API.  This API should take the WebCrypto to the applications that the existing technology covers but without being bogged down by legacy stuff like NSS, PKCS #11 or ISO 7816.



“Specifically designed” makes it sound like you are proposing something totally new (not HSM, TPM, SE,TEE, etc etc)

It would follow U2F which means fixed API, different hardware implementations.
The most important would probably be implementing such an API as a TA (Trusted Application) running in a GP TEE.
I would be like Nokia's ObC (ask Jan-Erik...) but this time it would be for real!

I hope this cleared-up at least my take on the subject.

Regards
Anders Rundgren



One purpose doesn’t sound very flexible but maybe I am over-reading your statement.


Regards

Don Felton



From: Anders Rundgren [mailto:anders.rundgren.net@gmail.com]
Sent: 03 November 2014 18:25
To: Sanjeev Verma
Cc: public-web-security@w3.org<mailto:public-web-security@w3.org>
Subject: Re: [Web Crypto Next] FIDO - Lets start discussing !

On 2014-11-03 17:56, Sanjeev Verma wrote:
Anders, Siva,

Thanks for your input. Probably I had a different understanding of the line of argument.  FIDO UAF specification also defines DOM APIs that enable Web apps to discover capabilities of the authenticator devices.  If the idea is to standardize the “pipe” for plug-ins that will accommodate the requirements of FIDO & other solutions then it makes sense.  I also meant the same.

Hi Sanjeev,
I believe there are several essentially independent projects on the table.
I would be quite cautious about mixing them.

The "pipe" (SE/7816?) and the "box" (middleware?) which have been mentioned represent two different paths.

FWIW, I am personally only interested in extending the WebCrypto API and Architecture to do things which FIDO does not.
However, I would "borrow" one key characteristic of FIDO's U2F and that is creating new and for the purpose specifically designed hardware security technology rather than spending EONs of time pushing square pegs into round holes.  I believe that's pretty much what Apple did for Apple Pay as well.

Regarding cooperating with FIDO, I don't see the point except on a "political" level.  It would be like XML DSig where IETF did an RFC-version which hardly anybody read with the big difference that FIDO is a closed group.

Regards,
Anders





Best regards,

Sanjeev

From: Siva Narendra [mailto:siva@tyfone.com]
Sent: Saturday, November 01, 2014 3:00 PM
To: Anders Rundgren
Cc: Sanjeev Verma; public-web-security@w3.org<mailto:public-web-security@w3.org>
Subject: Re: [Web Crypto Next] FIDO - Lets start discussing !

I agree with Anders. In addition web browsers through multitude of plug-ins already support industry standard secure element applets. Some of these are common in European and Asian countries that are slowly now starting to come to the US. Especially because secure elements can now added without hardware device change as they are either already in the device (TEEs) or it is easy to add them (through SIM, USB, microSD, BLE, NFC).

FIDO (U2F, UAF, USF....or any other possible new flavors) could be one such applet. But I don't quite understand why it should be the only one. What we need to do is to standardize the "pipe" for plug-ins so all existing secure element applets (including new ones like FIDO) can leverage the web.
-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 Sat, Nov 1, 2014 at 12:25 AM, Anders Rundgren <anders.rundgren.net@gmail.com<mailto:anders.rundgren.net@gmail.com>> wrote:
On 2014-11-01 00:30, Sanjeev Verma wrote:
Hi Sanjeev,

I think your questions are highly motivated although I would like to start at a somewhat higher level.

What would the point be with "W3C-fication" of FIDO specifications?
No security-oriented SDO has ever attracted as many "´Gig Guns" (and small ones as well) in such a short time as FIDO so the market doesn't seem to be overly sensitive regarding the origin of things.

Working side-by-side on the same target is not very realistic since FIDO have closed WGs.

That I mentioned U2F is because it (IMO) has the "web flavor" which means simple and elegant.
U2F also has clear links to the WebCrypto API (which development I consider the most if not the only viable path ahead).

UAF (which I'm less knowledgeable about) looks awfully complex ("the framework syndrome") and rather vendor-oriented.
I would let these guys try the waters first :-)

Since neither U2F or UAF addresses the "old world" like eID there's definitely room for new technology which doesn't clash with FIDO.
As an example Android's <keygen> was designed almost 20 years ago and doesn't match popular security applications like mobile banking which therefore without exception are written as "Apps".

Regards,
Anders




Hello Anders, Siva,

This is Sanjeev from Samsung and I have been following this discussion thread with keen interest.  I am bit puzzled by specific reference to U2F specs in regards to FIDO specifications.

  FIDO U2F is very basic one and its scope is very narrow as rightly pointed by you. However, things are bit different when it comes to FIDO UAF specifications. FIDO UAF supports discovery APIs that enable a web app to discover capabilities of the supported authenticator devices--like crypto algorithms supported, Authenticator IDs etc. A web application can also request authenticator to generate origin specific keys and sign text messages ( for WYSIWYS ). Good thing here is that FIDO UAF supports a wide-variety of authenticator devices--roaming authenticators, authenticators bound to the device etc.

I am not saying that it supports all the requirements for the use case under discussions here but it seems to meet some of them. IMHO it makes sense to work closely with FIDO on specific requirements instead of looking for a parallel solution.

Thanks,

Best regards,

Sanjeev

-----Original Message-----
From: Anders Rundgren [mailto:anders.rundgren.net@gmail.com<mailto:anders.rundgren.net@gmail.com>]
Sent: Wednesday, October 29, 2014 9:07 PM
To: Siva Narendra
Cc: helpcrypto helpcrypto;public-web-security@w3.org<mailto:helpcrypto%3Bpublic-web-security@w3.org>
Subject: Re: [Web Crypto Next] Lets start discussing !

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>  <http://www.tyfone.com>/
/Voice: +1.661.412.2233<tel:%2B1.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>  <mailto: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