On Thu, May 3, 2012 at 4:27 PM, Wan-Teh Chang <w...@google.com> wrote:
David, Here are my review comments on https://wiki.mozilla.org/DOMCryptInternalAPI: 1. I don't understand the difference between the two methods that generate key pairs: PKGenerateKeyPair SigGenerateKeyPair
GenerateKeyPair(purpose:keyEncryption) GenerateKeyPair(purpose:Signature) I think this is due to France, and legacy requirements for different caps on encryption versus signature key strengths. I don't know if these are still concerns.
2. PKEncrypt just need a public key, not a key pair.
This is not correct for EC. To do PKEncrypt there, you must have both the source private key and destination public key available to perform ECDH key agreement. Then, put that agreed value through a key derivation function (digest), and finally symmetrically encrypt the random message symkey with the derived symkey. There is no reversible transform from something which can be calculated solely from the public key, unlike RSA. Please implement RSA and DSA with a second, null parameter, so that this use can be enabled for EC.
3. I suggest not assigning 0 to any algorithm enumerator. This allows the use of 0 as an invalid value. We can't use -1 because the type is unsigned long. So ALGORITHM_RSA should be 1 and ALGORITHM_DSA should be 2.
ALGORITHM_ECDSA should be in there as well. However, I do not agree with the idea of enumerating algorithms and modes separately. Down that path lies ECB and non-KDF agreed key usage.
4. Like PKDecrypt, Sign just needs aKeyID, which represents a private key.
Sign needs to know some of the metadata associated with the keyID, I should think? Particularly for ECC certificates, SEC1 specifies an alternate encoding where the parameters are inherited from the certifier. If NSS stores these parameters for the private key regardless, I shall withdraw this objection. -Kyle H
-- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
