[whatwg] DOMCrypt update: July 14 Meeting Report

Silvia:

The design - at this time - allows the client to encrypt data locally, with the publicKey of the recipient - not allowing anyone else to read the data. The callback that the web page provides which captures the decrypted data has full access to the decoded data.

I imagine the DRM scenario would be possible if the API was implemented server side, but I think it would be a rather weak system.

Generally, this API is designed for private messaging between 2 users, with an untrusted server (as well as all of the hashing, HMAC, sign and verify methods).

The use-cases are listed here: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPI/UseCases

Cheers,

David

----- Original Message -----
From: "Silvia Pfeiffer" <silviapfeiffer1@gmail.com>
To: "David Dahl" <ddahl at mozilla.com>
Cc: "WHATWG Proposals" <whatwg at lists.whatwg.org>
Sent: Tuesday, July 26, 2011 4:58:30 PM
Subject: Re: [whatwg] DOMCrypt update: July 14 Meeting Report

If I understand this correctly, then this is introducing a mechanism
for Web publishers to provide a secure service to users where the data
exchanged between the server and the UA is encrypted and not decodable
by anyone else listening in on that communication or getting access to
the data stored in the browser for that communication.

If so, could this be a means to provide a one-session-only decoding
key to a UA to decode a specially encoded piece of content (e.g. a
video) from a publisher? I am quite directly thinking that this could
be a first step towards providing DRM methodology in the browser, but
also for example for about having secure private video conversations
without needing to install browser plugins.

Apologies for taking this thread a bit off topic - I am just curious.

Cheers,
Silvia.


On Wed, Jul 27, 2011 at 5:59 AM, David Dahl <ddahl at mozilla.com> wrote:
> Hello All:
>
> Just a quick report on a DOMCrypt meeting that took place Thursday, 2011-07-14 at Mozilla in Mountain View.
>
> Summary:
>
> ? ?DOMCrypt is a high-level API that should be usable by web developers after a short period of study
> ? ?DOMCrypt will be designed and implemented so that it is difficult to "do the wrong thing"
> ? ?HASH and HMAC methods may be implemented first
> ? ?The Public Key API is the most useful, so it should be implemented before the symmetric encryption API
> ? ? ? ?Keypairs must be generated on a per-origin basis
> ? ? ? ?The Keypair for a specific origin cannot be used in another origin
> ? ?No private or wrapped key material will be accessible to content scripts
> ? ?Each implementation will provide a mechanism to clear keys
> ? ?A "Key ID" will be used to tell the decrypt method which (content inaccessible) private key to use to decrypt data
> ? ?The returned encrypted object format will be a raw ArrayBuffer
> ? ?The public key format will be a raw ArrayBuffer
> ? ? ? ?**We agreed to "have all the inputs and outputs be raw, unformatted ArrayBuffers, letting higher-level pure JS wrappers deal with conversion to application data formats until we understand better what higher-level formats would be useful"
> ? ?HASH and HMAC methods should be synchronous to make them simpler
> ? ? ? ?HASH and HMAC methods should be constructors
> ? ?We may implement the HASH and HMAC APIs first then the PublicKey API
>
> A wiki page with more detail is here: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Meeting-2011-07-14
>
> The DOMCrypt Spec is here: https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest
>
> Any comments and discussion will be most welcome.
>
> Regards,
>
> David Dahl
>

Received on Tuesday, 26 July 2011 15:26:10 UTC