- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Wed, 27 Jul 2011 08:41:47 +1000
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 <ddahl at mozilla.com> 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" <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. > > 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:41:47 UTC