W3C home > Mailing lists > Public > public-webcrypto@w3.org > June 2012

RE: Need for Smart Card support

From: Davenport, James L. <jdavenpo@mitre.org>
Date: Fri, 8 Jun 2012 13:37:49 +0000
To: 'Mitch Zollinger' <mzollinger@netflix.com>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>
Message-ID: <3A6E8C8330F58F4399A73D47E29A4AE60ADF7FFB@IMCMBX02.MITRE.ORG>
Good examples, Mitch! Smart cards need to be within scope, but I am concerned that this use case document
http://www.w3.org/2012/webcrypto/wiki/Use_Cases#Out_of_Scope

lists them as being out of scope.  I think we'll need to queue this up as a topic for a future call.

-Jim

From: Mitch Zollinger [mailto:mzollinger@netflix.com]
Sent: Tuesday, June 05, 2012 1:35 PM
To: public-webcrypto@w3.org
Subject: Re: Need for Smart Card support

The need to integrate with smart cards plays into another conversation that Mark Watson & I had today after the WebCrypto call: the difference between naming a key and uniquely identifying a key. In many situations, these can be one and the same, but there are a bunch of places where calling these out as two separate concepts is required.

One example is smart cards and another is pre-provisioned keys.

What if each key had two pieces of state information associated with it:
* The key name
* The unique identifier (which could be a GUID)

In the example of a smart card key, perhaps I know that I can address the key named "MasterCardAuthenticationKey" on all devices that have a special MasterCard smart card plugged in, but I also need the unique key identifier (a GUID) which allows me to understand which individual smart card I'm operating on. I need to know this unique key identifier for a few reasons:
* to map to a user who owns the smart card
* in case someone finds a major security flaw in the cards or someone leaks the keys and I have to revoke

Obviously GUIDs raise privacy issues. In the case of keys pre-provisioned against a specific origin, the GUID is only shown to that origin. The smart card case is more difficult, since the smart card can presumably be used with multiple origins and has a single identifier.

Given the above approach, we can use our pre-provisioned keys. Does the above approach also solve the smart card use case, at least within the scope of key naming / identification?

One last note: this approach can also work with keys created at runtime. The GUID could be randomly generated and has the additional benefit of allowing an application to know if the runtime key has changed since the last time the app was run.

Mitch

On 6/4/2012 7:12 AM, Davenport, James L. wrote:

Our sponsor needs the Crypto API to enable JavaScript programs to be able to request: "Hey, please sign this data using that smart card."



The term "smart card" is a generic term that includes Common Access Card (CAC) and Personal Identity Verification (PIV) cards.



-----------------------------

Smart Card Use Cases

-----------------------------

In all of the following use cases the user must be prompted for his PIN prior to signing with the smart card. Also, the system must display to the user the data that is being signed, so that he knows what he is signing.



Using smart cards to sign data submitted to internal company web apps:



a. An employee accesses the company web app where he can make changes to his employee benefits (dental, medical, eye). He enters the changes and presses Submit. The changes are signed using the employees' smart card and then sent to the web app which validates the signature and processes the benefits changes.



b. After an employee makes a business trip he accesses a company web app which allows him to fill in the trip expenses - hotel, car rental, airfare - for reimbursement. He enters the expenses and presses Submit. The changes are signed using the employees' smart card and then sent to the web app which validates the signature and processes for reimbursement.



c. An employee is on a business trip. At the end of each day he accesses his company's web app to enter hours worked. He enters the project number and hours worked and presses Submit. The changes are signed using the employees' smart card and then sent to the web app which validates the signature and enters the time charged on his time sheet.



Using smart cards to sign data submitted to public web apps:



d. An individual accesses his doctor's web app which has a form for authorizing release of medical records to another family member. The individual fills in the form and presses Submit. The form data is signed using the individual's personal smart card and then sent to the web app which validates the signature and releases the medical records to the family member.



e. An individual accesses his broker's web app which has a form for authorizing the transfer of funds from one stock to another. The individual fills in the form and presses Submit. The form data is signed using the individual's personal smart card and then sent to the web app which validates the signature and transfers the funds.



f. An individual accesses his bank's web app which has a form for authorizing the transfer of money from one account to another. The individual fills in the form and presses Submit. The form data is signed using the individual's personal smart card and then sent to the web app which validates the signature and transfers the money.



g An individual accesses his mortgage company's web app which has a suite of forms that must be completed for the purchase of a house. The individual fills in the forms and presses Submit. The form data is signed using the individual's personal smart card and then sent to the web app which validates the signature and concludes the purchase of the house.



h. A realtor has put together an offer on a house and uploaded it online. An individual opens his browser, enters the URL, and reviews the offer. He then checks a box to show that he agrees with the offer, signs it, and uploads it. The realtor then goes to the seller and makes the offer on behalf of the individual.



Jim Davenport  (on behalf of Jenn Dotson, James Garriss, Roger Costello)
Received on Friday, 8 June 2012 13:38:28 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 8 June 2012 13:38:29 GMT