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

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

From: Nico Williams <nico@cryptonector.com>
Date: Fri, 10 Jun 2011 15:33:46 -0500
Message-ID: <BANLkTinox_oQij2noc3+L=uZddPbx8aqCQ@mail.gmail.com>
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

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