[whatwg] DOMCrypt update: July 14 Meeting Report

[Silvia Pfeiffer]

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
>