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

Re: Need for Smart Card support

From: Mitch Zollinger <mzollinger@netflix.com>
Date: Tue, 5 Jun 2012 10:34:51 -0700
Message-ID: <4FCE433B.6000304@netflix.com>
To: <public-webcrypto@w3.org>
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 Tuesday, 5 June 2012 17:35:24 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 5 June 2012 17:35:25 GMT