988781 - Plugin whitelist request: Smart Card Browser Plugin

Status: VERIFIED FIXED

(Firefox Graveyard :: Plugin Click-To-Activate Whitelist, defect)

Description

[adriancrco]

<<Please supply the following information for new plugin whitelist requests>>

Plugin name: Smart Card Browser Plugin
Vendor: Adrian Castillo, Open Source Developer
Point of contact: [e-mail]
Current version: 0.6.8
Download URL: plugin.cardid.org/webcard.msi
Sample URL of plugin in use:  plugin.cardid.org

Plugin details: This plugin provides a bridge between the native PC/SC layer that allows the computer to communicate with smart cards and the Web page by exposing the PC/SC functionality to the javascript code running in the Browser. It's built using the FireBreath plugin framework.

Smart Card Browser Plugin

    File: npWebCard.dll
    Path: C:\Users\Adrian\AppData\Roaming\cardid\WebCard\0.6.8\npWebCard.dll
    Version: 0.6.8.0
    State: Enabled
    Smart Card Browser Plugin

MIME Type	Description	Suffixes
application/x-webcard	WebCard

Are there any variations in the plugin file name, MIME types, description, or version from one release to the next? NO

Are there any known security issues in current or older versions of the plugin? NO

Dear Mozilla, I would gladly move my plugin to whatever technology you suggest is the appropriate replacement. For Google Chrome I'm exploring the implementation using the NaCl interface, but I think this is Chrome proprietary and would not work in Firefox is that correct? I just need a thin layer that allows a web page to use the functionality provided by winscard.dll that ships with Windows and with pcsc-lite that ships with Mac OS and Linux.

Comment 1

[Benjamin Smedberg]

I think the thing we'd like to do most is directly integrate smart card reading into the web platform as a native API. cc'ing rbarnes so he can help figure out whether there's a spec or a place where a spec could be written.

I realize that it's a complex and large problem to spec this out, but I think it's worthwhile.

Comment 2

[Richard Barnes [:rbarnes]]

In brief: We're still trying to figure out what we want to do for hardware crypto.

There's been discussion of hardware token support in the context of the W3C WebCrypto API development, but it was ruled out of scope for the first version.  (See Bug 865789 for our implementation in software.)

We're at the stage right now where we're figuring out, along with W3C, what a web API to access hardware crypto would look like.  So this would be an opportune time to contribute some thoughts on what the API should be.  Some questions that have been discussed:
* How to moderate access?  (Clearly, it's bad to just open up a hardware token to the whole web)
* What's needed beyond the crypto functions that are currently in the API?  Certificate storage/retrieval?

Do you have a link with more description of your plugin?

Comment 3

[Benjamin Smedberg]

Builds for testing are now available at http://people.mozilla.org/~bsmedberg/plugin-whitelisting-91f6f3380041/

Please do a QA pass using a new Firefox profile to ensure that the plugin activates without a popup and appears as "Always Activate" in the addon manager. Report back in this bug when QA is complete. Please try to complete QA by the end of this week.

Comment 4

[adriancrco]

I completed testing with the Nightly build and the plugin activates correctly and appears as Always Activate.

Regarding the broader conversation on how to integrate cryptographic functionality into Firefox, I'd be delighted to contribute to the conversation. Currently my plugin is available at http://plugin.cardid.org

It basically provides a wrapper to PC/SC and exposes the list of smart card readers attached to the computer as a JavaScript object Readers. Each element in the connection has the methods Connect, Transcieve and Disconnect.

Although PC/SC has been around for many years now, the most significant implementations remain that of Microsoft in Windows and the pcsclite for Linux that is partially supported in Mac OS X. However, adoption of smart cards is not yet universal because PC/SC only provides a transport layer and applications in the cards remain proprietary. If we wanted to move things forward, I believe that it would be appropriate to leverage a standard like FIPS 201 that describes the card edge of a smart card that contains identity credentials in the form of digital certificates. Since there are multiple vendors of such cards it could be possible to gain some traction and rather focus on more important problems like the user experience (PKCS#11 for client certificates is really not that usable) and developer adoption (I got some inspiration to make things simple from the Persona project at Mozilla).

In fact, I believe that leveraging some of the effort done with Persona could help tremendously the adoption of smart cards. In particular, it would make sense to leverage the availability of NFC readers in mobile devices. The way I believe many of the problems could be solved is by focusing in having a transport layer built into the browser and let the specifics of each card to be managed by a plugin that can be downloaded from the server following a discovery mechanism, similar to what Microsoft has implemented with the Smart Card Plug-and-Play service in Windows 7.

Let me know where is the right forum to contribute my experience and I'll go there to continue the conversation.

Comment 5

[Richard Barnes [:rbarnes]]

Adrian, the right place is the W3C WebCrypto working group mailing list:
http://www.w3.org/2012/webcrypto/

They're currently planning a workshop on hardware crypto in September:
http://www.w3.org/2012/webcrypto/webcrypto-next-workshop/Overview.html

Comment 6

[Benjamin Smedberg]

Fixed for Firefox 30 beta in bug 992995.

Comment 7

[adriancrco]

Hi Mozilla,
I noticed that my plugin whitelisting is due to expire on Firefox 34. While I had the good chance to meet Richard Barnes last week in the W3C WebCrypto Workshop and some work will continue from that with other participants I'm not sure what I need to do to keep the current one working while we work for a better solution.
-Adrian

Comment 8

[Benjamin Smedberg]

Adrian, I'll email you off-list in a couple weeks: don't worry, you're not going to expire in FF34. As we start processing possible renewals, I'll want to know what kind of progress we've made on a webcrypto replacement.