This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The algorithm/method table does not have a check mark for PBKDF2 in the generateKey or importKey methods. https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#algorithms-index But the PBKDF2 section has definitions for generateKey and importKey. https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#pbkdf2 The right solution here is to add the check marks, I think. In addition, if you call importKey or generateKey, the resulting Key has an algorithm attribute that does not expose the length of the key. This, together with Bug 23159 and Bug 25094, seems to suggest we should just promote length to KeyAlgorithm, and remove RsaKeyAlgorithm.modulusLength and AesKeyAlgorithm.length. This would be a little redundant for EcKeyAlgorithm and DhKeyAlgorithm, but that doesn't seem tragic.
> In addition, if you call importKey or generateKey, the resulting Key has an > algorithm attribute that does not expose the length of the key. This, > together with Bug 23159 and Bug 25094, seems to suggest we should just > promote length to KeyAlgorithm, and remove RsaKeyAlgorithm.modulusLength and > AesKeyAlgorithm.length. This would be a little redundant for EcKeyAlgorithm > and DhKeyAlgorithm, but that doesn't seem tragic. Please keep a single bug to report. That way discussions about why I strongly disagree about length as a generic property can be discussed :) As it relates to PBKDF2, I don't think a .length() property makes sense. It doesn't provide a signal for effective strength (as it does for other key types), nor is it a reasonable proxy for entropy. That said, if you still feel otherwise, please file another bug.
I've updated the bug title to drop the length question. We still should have import/export for PBKDF2 keys.
Also HKDF and CONCAT should have checks for importKey
https://dvcs.w3.org/hg/webcrypto-api/rev/0d1cdb9d2360