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

On Fri, Jun 10, 2011 at 4: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.
> >
> > 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.
>

There are a lot of applications that run completely offline and/or locally,
and run within intranets, etc.  Not all applications are delivered by some
foreign web server on every load or beyond an initial installation (e.g.
chrome extensions).  There are plenty of use cases for these types of
applications.

There are a lot of mobile possibilities here as well, such as Sencha Touch
applications wrapped in a PhoneGap native shell.


>
> Data-at-rest encryption OTOH is big business since many years back.
>
> --Anders
>
>


-- 
................................................................

*Sencha*
Jarred Nicholls, Senior Software Architect
@jarrednicholls
<http://twitter.com/jarrednicholls>