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

RE: [Web Crypto Next] Lets start discussing !

From: <gil.bernabeu@globalplatform.org>
Date: Thu, 6 Nov 2014 13:29:06 +0000
To: GALINDO Virginie <Virginie.Galindo@gemalto.com>, "public-web-security@w3.org" <public-web-security@w3.org>, "helpcrypto helpcrypto" <helpcrypto@gmail.com>
CC: Anders Rundgren <anders.rundgren.net@gmail.com>, "s2.verma@samsung.com" <s2.verma@samsung.com>
Message-ID: <B7090DE4BA6E3243BA802057A59EBCD398A7F237@A1GTOEMBXV001.gto.a3c.atos.net>
Hi all,
GlobalPlatform proposal was trying to answer to the different facets of the requirements .

As summary of the proposal :

-          W3C : Crypto.next extension with selection of the crypto environment

-          APIs for standard services (and FIDO is the first one that we should focus as community)

-          GlobalPlatform : APIS for non standard services that GlobalPlatform offers to deliver

Regarding Virginie's email  about rechartering

-          Do you consider the selection of the environment as part of the Crypto.next charter ? if not Do GlobalPlatform community has any action here ?

-          About accessing secure token (re: not part of WebCrypto.next) , GlobalPlatform plan to launch the effort shortly and will invite W3C community to contribute.

Gil Bernabeu

From: GALINDO Virginie [mailto:Virginie.Galindo@gemalto.com]
Sent: jeudi 6 novembre 2014 14:01
To: public-web-security@w3.org; helpcrypto helpcrypto
Cc: Anders Rundgren; s2.verma@samsung.com
Subject: [+SPAM+]: Re: [Web Crypto Next] Lets start discussing !

Hello helpcrypto,

Few answers :

- I am not sure Anders is a reference,  here, rather a passionated and talkative person :)

- See my last e-mail on rechartering to understand where w3c is, on accepting smart cards

- FIDO is not part today of W3C scope, you should ask them directly your questions.


>From my mobile

---- helpcrypto helpcrypto a écrit ----


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?


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.
Received on Thursday, 6 November 2014 13:29:44 UTC

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