W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2011

Re: Request for feedback: DOMCrypt API proposal

From: David Dahl <ddahl@mozilla.com>
Date: Thu, 2 Jun 2011 16:46:01 -0700 (PDT)
To: Adam Barth <w3c@adambarth.com>
Cc: public-webapps@w3.org
Message-ID: <155909645.107895.1307058361202.JavaMail.root@zimbra1.shared.sjc1.mozilla.com>
----- Original Message -----
From: "Adam Barth" <w3c@adambarth.com>
To: "David Dahl" <ddahl@mozilla.com>
Cc: public-webapps@w3.org
Sent: Thursday, June 2, 2011 6:19:24 PM
Subject: Re: Request for feedback: DOMCrypt API proposal

> Why only SHA256?  Presumably sha1 and md5 are worth exposing as well.
  Also, pk and sym appear to be algorithm agonistic but hash isn't.  In
  addition to hashing, it would be valuable to expose HMAC modes of the
  hash functions.

hash should probably have SHA512 as well, also, I just added an hmac API to the spec.

> In the pk API, there doesn't seem to be any way to install a
  public/private keypair from another location (e.g., the network).

No, there is not. Can you suggest what that API would look like? Importing keys should be allowed.

> Also, the encrypt and decrypt functions don't let me specify which
  public key I want to use.  Consider introducing a keyID concept to let
  me refer to keypairs.

Hmmm, I updated the wiki today as I forgot to include the pubKey on encrypt(). There should be a setter and getter for specifying the keypair to use. 

> What is a cipherAddressbook ?

It is an object literal that you store discovered public keys in - which are referred to as "addressbook entries". The Addressbook bits of this API will have to wait for their own spec I think. i was trying to allow for key discovery and storage in the simplest way possible: a custom tag or meta tag is published on your blog and your contacts are alerted by the browser during a visit to the page. The user can then store that 'addressbook entry' (or key) for later use.


> When I use generateKeypair, how long dose the keypair persist?  Is are
  their privacy implications?
There is nothing in the spec right now. I should probably use a standard cert type that declares validity dates.

> Finally, this all should be on the crypto object, not on a new cipher object.

More and more people are saying that. 

Thanks,

David


On Wed, Jun 1, 2011 at 3:54 PM, David Dahl <ddahl@mozilla.com> wrote:
> Hello public-webapps members,
>
> (I wanted to post this proposed draft spec for the DOMCrypt API ( https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest ) to this list - if there is a more fitting mailing list, please let me know)
>
> I recently posted this draft spec for a crypto API for browsers to the whatwg (see: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-May/031741.html) and wanted to get feedback from W3C as well.
>
> Privacy and user control on the web is of utter importance. Tracking, unauthorized user data aggregation and personal information breaches are becoming so commonplace you see a new headline almost daily. (It seems).
>
> We need crypto APIs in browsers to allow developers to create more secure communications tools and web applications that don’t have to implicitly trust the server, among other use cases.
>
> The DOMCrypt API is a good start, and more feedback and discussion will really help round out how all of this should work – as well as how it can work in any browser that will support such an API.
>
> This API will provide each web browser window with a ‘cipher’ property[1] that facilitates:
>
>    asymmetric encryption key pair generation
>    public key encryption
>    public key decryption
>    symmetric encryption
>    signature generation
>    signature verification
>    hashing
>    easy public key discovery via meta tags or an ‘addressbookentry’ tag
>
> [1] There is a bit of discussion around adding this API to window.navigator or consolidation within window.crypto
>
> I have created a Firefox extension that implements most of the above, and am working on an experimental patch that integrates this API into Firefox.
>
> The project originated in an extension I wrote, the home page is here: http://domcrypt.org
>
> The source code for the extension is here: https://github.com/daviddahl/domcrypt
>
> The Mozilla bugs are here:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=649154
> https://bugzilla.mozilla.org/show_bug.cgi?id=657432
>
> Firefox "feature wiki page": https://wiki.mozilla.org/Privacy/Features/DOMCryptAPI
>
> You can test the API by installing the extension hosted at domcrypt.org, and going to http://domcrypt.org
>
> A recent blog post updating all of this is posted here: http://monocleglobe..wordpress.com/2011/06/01/domcrypt-update-2011-06-01/
>
> The API:
>
> window.cipher = {
>  // Public Key API
>  pk: {
>   set algorithm(algorithm){ },
>   get algorithm(){ },
>
>  // Generate a keypair and then execute the callback function
>  generateKeypair: function ( function callback( aPublicKey ) { } ) {  },
>
>  // encrypt a plainText
>  encrypt: function ( plainText, function callback (cipherMessageObject) ) {  } ) {  },
>
>  // decrypt a cipherMessage
>  decrypt: function ( cipherMessageObject, function callback ( plainText ) { } ) {  },
>
>  // sign a message
>  sign: function ( plainText, function callback ( signature ) { } ) {  },
>
>  // verify a signature
>  verify: function ( signature, plainText, function callback ( boolean ) { } ) {  },
>
>  // get the JSON cipherAddressbook
>  get addressbook() {},
>
>  // make changes to the addressbook
>  saveAddressbook: function (JSONObject, function callback ( addresssbook ) { }) {  }
>  },
>
>  // Symmetric Crypto API
>  sym: {
>  get algorithm(),
>  set algorithm(algorithm),
>
>  // create a new symmetric key
>  generateKey: function (function callback ( key ){ }) {  },
>
>  // encrypt some data
>  encrypt: function (plainText, key, function callback( cipherText ){ }) {  },
>
>  // decrypt some data
>  decrypt: function (cipherText, key, function callback( plainText ) { }) {  },
>  },
>
>  // hashing
>  hash: {
>    SHA256: function (function callback (hash){}) {  }
>  }
> }
>
> Your feedback and criticism will be invaluable.
>
> Best regards,
>
> David Dahl
>
> Firefox Engineer, Mozilla Corp.
>
>
>
Received on Thursday, 2 June 2011 23:46:31 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:45 GMT