Feedback and criticism wanted: DOMCrypt API proposal

David Dahl ddahl at mozilla.com
Mon Jun 6 09:51:51 PDT 2011


----- Original Message -----
From: "Bill Frantz" <frantz at pwpconsult.com>
To: "David Dahl" <ddahl at mozilla.com>
Cc: es-discuss at mozilla.org
Sent: Monday, June 6, 2011 11:00:29 AM
Subject: Re: Feedback and criticism wanted: DOMCrypt API proposal

On 6/1/11 at 16:01, ddahl at mozilla.com (David Dahl) wrote:

>A JSON Object which labels the Key Pairs, staring with a "default" Key Pair. This allows for multiple Key Pairs in the future.
>
>01. {
>02. "default": {
>03. "created"   : 1305140629979,
>04. "privKey"   : <BASE64 ENCODEDED PRIVATE KEY>,
>05. "pubKey"    : <BASE64 ENCODEDED PUBLIC KEY>,
>06. "salt"      : <ENCODED or ENCRYPTED Salt>,
>07. "iv"        : <ENCODED or ENCRYPTED IV>,
>08. "algorithm" : "AES_256_CBC",
>09. }

> This example seems to define public and private keys for a 
  symmetric algorithm. The detailed format of public keys will 
  depend on which algorithm is used. Are you planning on storing 
  them in their ASN1 form, or as JSON objects?

This is in flux right now. It looks like we will be moving to a keyID mechanism that ties your use of the keypair to the origin where it was generated. In which case, the current way the implementation stores the keys will change to the standard why NSS uses keys. The spec is undergoing a lot of editing right now starting with a proper WebIDL representation. 

There is a lot of discussion in this API on the web-app-security list: 

http://lists.w3.org/Archives/Public/public-web-security/2011Jun/0000.html

Many questions and answers have been summarized from the whatwg and w3c here: http://etherpad.mozilla.com:9000/DOMCrypt-discussion

>window.mozCrypto
>All windows will have this property (in the current implementation) for the time being as this API is hashed out.
>
>The property is namespaced in order to provide future capabilities. The current design is asynchronous and looks like this:

> Is an asynchronous interface the best choice. I thought one of 
  the great reliability advantages of Javascript was its single 
  thread, synchronous nature.

Browsers almost by default will frown on including any synchronous APIs. With Firefox, we just don't want any additional main thread I/O happening.

Regards,

David 


More information about the es-discuss mailing list