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 [helpcry...@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.gali...@gemalto.com<mailto:virginie.gali...@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.ve...@samsung.com<mailto:s2.ve...@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
<s...@tyfone.com<mailto:s...@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
