[whatwg] DOMCrypt update: July 14 Meeting Report

[Silvia Pfeiffer]

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
>>
>