- From: Anders Rundgren <anders.rundgren@telia.com>
- Date: Sat, 11 Jun 2011 07:32:13 +0200
- 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