RE: Proposed API extension for Fido U2F devices

Hi all,

In order to avoid mixing everything, I suggest that we classify that conversation in the future work of that W3C Web Crypto WG.

At the moment, the collection of future work is maintained on our wiki : http://www.w3.org/2012/webcrypto/wiki/WG_Future_Work and I suggest the sponsors of the U2F feature to amend that wiki with references to their proposals. On my side I do have a question wither others contributions from FIDO will be landing there, as there are other technologies developed in this SDO.

The U2F use case is one specific use case which is bringing new features to the web crypto API. I do not see why the existence of the U2F would preclude the discussion related to the integration of hardware token (or any secure element) in the web crypto, for which we have imagined to have a workshop this year. Note that It is still on my side to propose a strawman proposal for the workshop.

Hope it helps,
Regards,
Virginie
Chair of the web crypto wg


From: Ryan Sleevi [mailto:sleevi@google.com]
Sent: lundi 10 février 2014 09:31
To: Siva Narendra
Cc: Harry Halpin; Juan Lang; public-webcrypto-comments@w3.org
Subject: Re: Proposed API extension for Fido U2F devices



On Sun, Feb 9, 2014 at 12:11 PM, Siva Narendra <siva@tyfone.com<mailto:siva@tyfone.com>> wrote:

Hi Juan and everyone.

Smart Card support which is already a hardware standard and it is well know what language it speaks (ISO7816) should be considered as an alternative to new and yet to be common U2F hardware standard.
U2F was designed with the web and the web security requirements in mind.

I do not believe it would at all be appropriate for security to consider exposing ISO7816-devices to the web.


As you all know smart cards are not only already a standard, it has sold in the billions and costs as little as $0.60.

In addition,  Public key methods (without using PKI) is already well supported with repurposed smart card security applets such as PKCS #15 that can work with existing server infrastructure with very minimal change, to enable for eg mutually authenticated TLS connection with no need for 3-party PKI. We already have this working in Firefox where the smart card is connected to the device in one of many possible ways.
Very few smart cards support PKCS#15. It's well understood that a variety of card edges exist - often custom and proprietary.

Further, as has been discussed repeatedly in the past, the security model of TLS client certificate authentication - where neither party directly controls the resulting message being signed and reliance on a 'trusted' (read: installed) program (the UA and/or middleware, depending on OS API used) is used to perform the signing - is _vastly_ different than allowing arbitrary JS access to a smart card.


Not to mention smart card applets are extensible to any future standard such as the yet to be released NIST standards on derived credentials for government use.

In addition smart cards are the only security hardware that have well defined and well followed security certification across multiple industry verticals.

It would be unproductive to consider hardware without smart cards as part of it.
I strongly believe that it would be far more unproductive to consider smart cards, in their vast, non-standard specific use cases and distinct security models and risks, versus something with a very defined, limited scope, and with strong browser/industry involvement on defining something actually suitable for the web.

Dear Harry - What is the expected timing of considering hardware extension? We will take ownership in writing an alternative to U2F that is smart card based.
If and when this WG is rechartered, we can revisit whether or not hardware tokens are in scope. The biggest determinant for deciding whether or not they are in scope will require a demonstration that the many security issues that have been highlighted during the F2F and on the list can be sufficiently resolved. This seems extremely unlikely for the general smart card case, whereas the U2F proposal clearly demonstrates attention to these concerns (even though it can use refinement/improvement)

Cheers,
Ryan
Best regards,
Siva


--
Siva G. Narendra Ph.D.
CEO - Tyfone, Inc.
Portland | Bangalore | Taipei
www.tyfone.com<http://www.tyfone.com>
Voice: +1.661.412.2233<tel:%2B1.661.412.2233>


On Sun, Feb 9, 2014 at 2:04 AM, Harry Halpin <hhalpin@w3.org<mailto:hhalpin@w3.org>> wrote:
On 02/04/2014 10:41 PM, Juan Lang wrote:
Hi folks,
I'm aware that hardware-backed keys are out of scope for the current round of WebCrypto work, so I don't expect this to be ready for standardization for some time. Nevertheless, I've got a proposed extension to WebCrypto to support Fido Alliance (fidoalliance.org<http://fidoalliance.org>) universal second factor (U2F) devices:
https://docs.google.com/a/chromium.org/document/d/1EEFAMIYNqZ7XHCntghD9meJwKgNOX7ZN-jl5LJQxOVQ/edit#<https://docs.google.com/a/chromium.org/document/d/1EEFAMIYNqZ7XHCntghD9meJwKgNOX7ZN-jl5LJQxOVQ/edit>

I apologize that the proposal may lack some context, like, just what is a U2F device, and what language does it speak? I promise update it with pointers to public docs once they are made public. In the meantime, I'll act as a poor substitute by answering questions myself, either in the doc or in email.

I'd appreciate any feedback you might have. Thanks very much,
--Juan

I haven't had to look at this in detail, but upon first look it seems sensible. The general direction is one that the W3C is actively interested in. While this would be outside the current charter, we will re-charter the Working Group once the current version of WebCrypto (at earliest) has exited Last Call and working with FIDO Alliance would likely be mutually beneficial.

    cheers,
      harry



________________________________
This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus