W3C home > Mailing lists > Public > public-web-security@w3.org > June 2011

Re: Smart Card support. Re: Request for feedback: DOMCrypt API proposal

From: Anders Rundgren <anders.rundgren@telia.com>
Date: Sat, 11 Jun 2011 07:32:13 +0200
Message-ID: <4DF2FDDD.4080405@telia.com>
To: Nico Williams <nico@cryptonector.com>
CC: Brian Smith <bsmith@mozilla.com>, public-web-security@w3.org, Jarred Nicholls <jarred@sencha.com>, David Dahl <ddahl@mozilla.com>
On 2011-06-10 22:33, Nico Williams wrote:
<snip>
>> Since the merchant, hotel, whatever needs the credit card number in clear
>> in order to reserve money this is an example which DOMCrypt does not address.
> 
> Not so.  They need to not hold on to that data after the transaction
> is complete (else it tends to get stolen, which reflects very badly on
> them).  But they also want to hold on to that data for the user's
> convenience (so that they don't have to keep re-entering the same data
> over and over.  So, for each transaction the client sends the data
> unencrypted (over TLS though, with confidentiality protection), but
> the client also gets and sends profile ciphertext, with the client
> decrypting that ciphertext to get at the data to send for the one
> transaction.

I think I will drop this thread since you are now *way* off from a
realistic use-case.  Merchants and Hotels are not going to wait
for the client to decrypt data.

> Of course, the serve could do all that on the server side just as
> well.  But I think there's benefits to doing profile
> decryption/encryption on the client side.

If cryptographers ruled the world but they don't.

As a final note I would like to mention the "epic fail" of Microsoft's
Information Card project, which at least in my mind didn't take the
alternatives in consideration.  I.e, many banks in the EU and Asia
spend *huge* sums on developing browser security plugin SW since the
browser vendors ignore their fairly humble needs such as during
provisioning assigning a PIN to a PKI soft token.  Can't be done in
any browser!

Anders
Received on Saturday, 11 June 2011 05:33:19 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:26:19 UTC