- From: Nico Williams <nico@cryptonector.com>
- Date: Fri, 10 Jun 2011 15:33:46 -0500
- To: Anders Rundgren <anders.rundgren@telia.com>
- Cc: Brian Smith <bsmith@mozilla.com>, public-web-security@w3.org, Jarred Nicholls <jarred@sencha.com>, David Dahl <ddahl@mozilla.com>
On Fri, Jun 10, 2011 at 3:17 PM, Anders Rundgren <anders.rundgren@telia.com> wrote: > On 2011-06-10 22:04, Brian Smith wrote: >> Nico Williams wrote: >>> Which reminds me of OTR. But note that in the case of profile data >>> including credit card numbers the service has a very strong incentive >>> to store the data encrypted and do the crypto on the client-side: >>> civil liability, which is what overcomes my script trust issues. The >>> same doesn't apply to private messaging, yet. > > 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. 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. Nico --
Received on Friday, 10 June 2011 20:34:18 UTC