W3C home > Mailing lists > Public > public-web-security@w3.org > February 2012

Re: Request for feedback: DOMCrypt API proposal

From: David Dahl <ddahl@mozilla.com>
Date: Wed, 22 Feb 2012 13:58:37 -0800 (PST)
To: Frederick Hirsch <Frederick.Hirsch@nokia.com>
Cc: public-web-security@w3.org
Message-ID: <1893683289.198216.1329947917638.JavaMail.root@zimbra1.shared.sjc1.mozilla.com>
----- Original Message -----
> From: "Frederick Hirsch" <Frederick.Hirsch@nokia.com>
> To: ddahl@mozilla.com
> Cc: "Frederick Hirsch" <Frederick.Hirsch@nokia.com>, public-web-security@w3.org
> Sent: Wednesday, February 22, 2012 3:06:50 PM
> Subject: Re: Request for feedback: DOMCrypt API proposal
> 
> Is the difference of approach  and methods between DOMCrypt and
>  node.js due to a desire to have async callbacks in DOMCrypt?
> Will the differences create any adoption/portability concerns?
> 
> for example
> 
> DOMCrypt:  CryptoHash with a method to append data to a buffer and
> then "hash" to create the hash
> 
> node.js: crypto.createHash(algorithm), hash.update(data), hash.digest
> 
I would say that the spec for Hashing is still up in the air. What we have now in the spec is a starting point. I will make a mental note to make some comparisons between what node is doing and what we are planning. There is a Hashing component in Gecko called nsICryptoHash that does things like node.

> or more interestingly
> 
> DOMCrypt: sign(key, plaintext), callback with signature
> 
> node.js: crypto.createSign(algorithm), signer.update(data),
> signer.sign(privatekey)

Handling the private key in web content is bad practice, so that is perhaps a major difference between node and DOMCrypt (in this case). This may be an unbridgeable divide, however, I can see a helper utility that might be able to equalize the interfaces in practice.

> 
> What are the options for key pair generation. node.js allows
> DiffieHellman and pbkdf2, what is the algorithm support intended for
> DOMCrypt?

This may depend on the implementation, however, for Public Key Crypto, RSA/256/2048 will be the starting option. This will of course be configurable for future algorithm upgrades.

For Symmetric crypto the thinking is to use DHKE, see the Netflix use case: http://www.w3.org/wiki/NetflixWebCryptoUseCase
> 
> Where in DOMCrypt is the signing algorithm specified - in general,
> what is the approach toward algorithm agility?
You will create signing keys via the public key method: generateKeypair(DOMString algorithm, GenerateKeypairCallback callback, boolean signingKeypair);

You will be able to specify (this is implementation specific right now) RSA/256/2048, DSA/160/1024 and ECDSA (not sure about the specifics yet) for signing keypairs.

> 
> (I see in the blog [1] methods to specify the algorithm, but not in
> the draft spec [2], are both defining the API?)
> 
> Presumably the algorithm support will be limited by OpenSSL?

Each implementation may have limitations as far as algs are concerned. I hope not. As far as Firefox is concerned we are limited by NSS, and if NSS is lacking any algorithms we can implement them - which of course will take time. I should hope each implementation has a common base of algorithms to use.

We should see the spec move to W3's server next month along with tweaks and clarifications like this.

Thank you for asking these questions.

Regards,

David
Received on Wednesday, 22 February 2012 21:59:05 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 22 February 2012 21:59:05 GMT