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

Re: Need for Smart Card support

From: Harry Halpin <hhalpin@w3.org>
Date: Fri, 08 Jun 2012 17:56:25 +0200
Message-ID: <4FD220A9.8040807@w3.org>
To: "Davenport, James L." <jdavenpo@mitre.org>
CC: 'Mitch Zollinger' <mzollinger@netflix.com>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>
On 06/08/2012 03:37 PM, Davenport, James L. wrote:
>
> 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.
>

Note that smart-cards themselves are not out of scope, as we expect them 
to be possibly used as a source of key material of course, and these 
use-cases are great.

Just to clarify the charter [1], what we are trying to avoid is adding 
special smart-card related provenance to the key identification scheme 
or method calls to the API. The key identification schemes for 
smartcards, like any other device, is very application dependent and as 
the space of possible things one would want to put in the key 
identification (*directly*, i.e. "special handling directly for 
non-opaque key identification"). Second, as the range of device-specific 
method calls is also potentially very infinite, what we'd hope is that 
the API treats smart-cards as just another container, and then WebApps 
that can recognize that is a container for a smartcard (likely using 
proprietary method calls, not standardized ones) and then apply that 
smart-card+app specific identificaiton scheme to make sure it knows the 
origin of the key.

[1]http://www.w3.org/2011/11/webcryptography-charter.html
>
> -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 15:56:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 8 June 2012 15:56:35 GMT