W3C home > Mailing lists > Public > public-web-security@w3.org > November 2014

RE: [Web Crypto Next] Lets start discussing !

From: Sanjeev Verma <s2.verma@samsung.com>
Date: Thu, 06 Nov 2014 21:22:53 +0000
To: helpcrypto helpcrypto <helpcrypto@gmail.com>, "public-web-security@w3.org" <public-web-security@w3.org>
Cc: Anders Rundgren <anders.rundgren.net@gmail.com>, "Virginie.Galindo@gemalto.com" <Virginie.Galindo@gemalto.com>
Message-id: <E4DEE1A55C608B408F895F05C05C6993A1C75739@sisaex02sj>
Hello HelpCrypto,

It is true that FIDO is not an open organization but you can download the specs from their website.


FIDO U2F addresses a very different use case (primarily for mobile payment or strong authentication) —it allows a user to carry a Web Key-Chain in the hardware token. It generates a public-private key pair for a Relying Party and sends the public key & a key handle to the Relying party (RP)at registration time. The Relying party identifies the key through a key handle. Later it is used for authentication between the user and the Relying party: the user first authenticates to the RP using PIN/Password and then authenticates ( second factor) to the RP by signing the challenge using the  private key.

You are talking about a different use case where the hardware token stores certs from different CAs to sign documents. FIDO specs currently do not address this use case.

Probably you should have a look at the email conversation that I had with Siva. I was thinking more in terms of standardizing the Web App-Plugin interface ( “pipe”) that will accommodate both FIDO use case and the use case that you are referring to.

Best regards,


From: helpcrypto helpcrypto [mailto:helpcrypto@gmail.com]
Sent: Thursday, November 06, 2014 12:44 AM
To: public-web-security@w3.org
Cc: Anders Rundgren; Sanjeev Verma; Virginie.Galindo@gemalto.com
Subject: Re: [Web Crypto Next] Lets start discussing !


Anders: as you seem to have the decisive voice in here, since our last talk, what has changed?

As you know, I'm of the opinion that is better to keep smartcards as secure elements where keys can be stored, than throwing all to the recycle bin.
In our case we have a JavaCard, so we could even stablish a mutual trust channel between server and card for population process. Older cards are probably a bigger problem ;)
It's true that PKI doesnt support "key usages for specific domains", something FIDO does. Does anyone know a way to implement this using traditional PKI?
Can you imagine/describe a secure/valid scenario where smartcards are one possible secure keystore for a PKI cert, being possible to auth+sign documents using Javascript? (do it with all the effort/strengh of your imagination!!!)

Sanjeev: AFAIK, FIDO group is not open neither open to community participation.
IIRC, there was a possibility of loading a FIDO applet inside my Javacard+requesting a PIN to login, even a RAW/APDU spec.

As FIDO is not PKI based, will that mean I have to dump what I already have? (millions of certs from different CAs used by millions of users to auth and sign documents?

Actually we do this using an awful applet, and thats what we want to avoid.

Perfect is the enemy of good. Perhaps we should reach an agreement-solution.
PS: Virgine (): based on your experience, does people from the Webcrypto WG have anything to say related to this? I know smartcards were out of scope. were the different viewpoints the reason? do they 'like' the idea of including smartcards on spec? Do manufacturer/providers/vendors/big actors have something to say? is FIDO what they say?


Received on Thursday, 6 November 2014 21:23:25 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:26:22 UTC