OK, so it would apply to a private video conference, but not to protect a server-client-delivery. That's good to know, thanks. Silvia.
On Wed, Jul 27, 2011 at 8:26 AM, David Dahl <[email protected]> wrote: > 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" <[email protected]> > To: "David Dahl" <[email protected]> > Cc: "WHATWG Proposals" <[email protected]> > 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 <[email protected]> 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 >> >
