RE: [Web Crypto Next] Lets start discussing !

Hello,

Some long overdue thoughts from my side as well:

1. I remember reading from WebCrypto mailing list/bugzilla a discussion that basically came down to "we need to consider what browsers out there currently already implement and the environment they operate in" (IIRC the context was Curve25519). Thus catering for existing infrastructure (platform integration, also existing pre-distribtued keys) should be "important" from WebCrypto perspective ?

2. I'm strongly against exposing an APDU-layer interface to the web and consider the "hardware token access" problem solved by that. First, because it has nothing to do with "pure cryptography" as implemented by current WebCrypto and second, I would be comparable to opening a JS api for ATA commands when the use case would be uploading a file from the file system of the hard disk. Most phones don't have hard disks, for example.

Understandable is the wish of token vendors to remain operating on a layer they consider a norm and "universal solution" but that would be a serious fallback IMHO. Would website operators want to re-implement the knowledge of drivers, real life issues with drivers containing lots of logic and even "sensitive keys" (a stupidity but reality).

Whatever the solution, a very proper "permissions" scheme must be thought out for accessing either bare tokens or pre-provisioned keys.

3. One important aspect is the rise of new (mobile) platforms (in addition to "web as a platform") and the fact that the "tricks" that the PKI smart card industry has learned to do to live with the desktop platforms (plugins, platform drivers etc) do not translate well to mobile platforms ("Platform keystores" on iOS or Android with user-installable plugins/providers, anyone?). Architecture-wise i'd like to see app-store installable keystore providers that could make use of either NFC or USB-CCID and WebCrypto API in the browser that talks to the provider, rather than a direct pipe from web to NFC reader hardware.... Of course, I'm sure handheld platform vendors would like to be the sole gatekeeper of everything on the device, so "rent-seeking activities" is a real risk for anything that should be part of the *open* web architecture.

4. Because browser vendors are making plugins a no-go territory local (JSON, XML or similar) RPC services on 127.0.0.1 are becoming a new norm (I know at least a handful independent implementations), with new risks and challenges. I would like to avoid going there. While in-browser RPC over TCP sockets is definitely platform-Internet-compatible I doubt it is something we'd like to call the future of platform-web ?

5. There's a picture of what I hope will be the future: http://martinpaljak..net/web_signing.pnghttp://martinpaljak.net/web_signing.png
 - for a long time, websites made use of java applets that required a lot of code from website managers (and often were different versions and buggy) that talked to PKCS#11 or platform keystores, mostly. As Java did not grow javax.smartcardio support until Java itself was not popular any more, access to PC/SC did not happen that much.
 - currently there are plenty of plugins around that talk to either platform stores, PKCS#11 or even directly to PC/SC. But as plugins are getting phased out, we need to come up with something new
 - The future I hope is one where browser-provided JS interface allows to access keys in the operating environment of the browser, that would include pre-provisioned keys accessible through whatever mechanisms the platform exhibits for that purpose (Windows and OSX have some, not sure about mobile things or Linux, which is a mix of many things).

As said, we have a set of plugins currently, that expose a simple .listCertificates() and .sign() functionality for IE, FF, Chrome and Safari. Now it would be nice if I could somehow securely adjust the otherwise fixed UI to match my site, at the same time I really like that the plugins trigger platform-specific API-s with a known look and feel (CNG). Still no overview page and source code to collaborate on but not very far.

Ideas or more exact suggestions, anyone?


Regards,

Martin



________________________________
From: helpcrypto helpcrypto [helpcrypto@gmail.com]
Sent: Friday, November 07, 2014 10:53
To: public-web-security@w3.org
Subject: Re: [Web Crypto Next] Lets start discussing !

On Thu, Nov 6, 2014 at 2:01 PM, GALINDO Virginie <Virginie.Galindo@gemalto.com<mailto:Virginie.Galindo@gemalto.com>> wrote:
    Hello helpcrypto,
    Few answers :
    - I am not sure Anders is a reference,  here, rather a passionated and talkative person :)
Probably a translation issue. I mean someone who is very participative and active. ;)


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


    - FIDO is not part today of W3C scope, you should ask them directly your questions.
    Virginie
As usual, thanks for your time, patience and support.



On Thu, Nov 6, 2014 at 10:22 PM, Sanjeev Verma <s2.verma@samsung.com<mailto:s2.verma@samsung.com>> wrote:
Hello HelpCrypto,

It is true that FIDO is not an open organization but you can download the specs from their website.
https://fidoalliance.org/specifications/download/
That doens't fix the problem of restricted participation ;)

Quoting you:
> IMHO it makes sense to work closely with FIDO on specific requirements instead of looking for a parallel solution.
How could we (work closely with FIDO)?


 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.
Sure, U2F self-explain pictures are clear on this.


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.
IIUC you are refereing to UAF, isnt it?. I will have a look on it.

My point is: FIDO is really cool to login without pass/U2F, but missed (probably on purpose) the widely-used used-case of document signing.
I would love to see this included on a next version, adopted by browsers, and we using it while ending with my painful relation with Java Applets.

Thanks a lot for your kind answers



On Thu, Nov 6, 2014 at 11:46 PM, Siva Narendra <siva@tyfone.com<mailto:siva@tyfone.com>> wrote:
 Agreed. The question is where does such an effort belong within W3C. Webcrypto WG may not
 be the right place for it within W3C given the WG's charter. The "pipe" maybe best done in a
 stand alone WG only because there are various efforts including unfinished ones such as the
 Gemalto+Deutsche Telecom's SE API proposal to W3C.
Shall this discussion also be done at other place instead?



Regards