[whatwg] DOMCrypt update: July 14 Meeting Report
silviapfeiffer1 at gmail.com
Tue Jul 26 15:41:47 PDT 2011
OK, so it would apply to a private video conference, but not to
protect a server-client-delivery. That's good to know, thanks.
On Wed, Jul 27, 2011 at 8:26 AM, David Dahl <ddahl at mozilla.com> wrote:
> 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
> ----- Original Message -----
> From: "Silvia Pfeiffer" <silviapfeiffer1 at 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.
> 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.
>> 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.
>> David Dahl
More information about the whatwg