- From: Anders Rundgren <anders.rundgren@telia.com>
- Date: Fri, 10 Jun 2011 22:17:50 +0200
- To: Brian Smith <bsmith@mozilla.com>
- CC: Nico Williams <nico@cryptonector.com>, public-web-security@w3.org, Jarred Nicholls <jarred@sencha.com>, David Dahl <ddahl@mozilla.com>
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. > > AFAICT, for this use case, we just need a simple API that says "store this data encrypted with assurance level <X> of confidentiality, requiring assurance level <Y> of authentication to unlock, and restricted to content from origin <Z>" similar to what Microsoft Exchange does for mobile devices. > > Even if you had an explicit crypto API, you would need the above API anyway, for protecting the keys, right? > 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. Unfortunately there are few use-cases for data encryption (in contrast to transport encryption), that survives the litmus test. Data-at-rest encryption OTOH is big business since many years back. --Anders
Received on Friday, 10 June 2011 20:18:55 UTC