This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
There is currently an awkward interaction for how import/export works for the KDFd (PBKDF2, HKDF, Concat-KDF): * You can importKey(extractable=true), however the exportKey() operation is not supported. So in truth you can never actually export these keys. It is less then ideal to accept extractable=true during import, but create a key which is effectively unextractable. * You can unwrapKey() for the KDFs (because they support the importKey() operation), however the converse is not true (you cannot wrapKey() because exportKey() is unsupported). It is strange that you could unwrap something (perhaps created directly using encrypt()), but cannot directly wrap it. (If you wrap will get NotSupportedError) I think the most consistent behavior would be to simply define exportKey() operation for these algorithms. Let callers specify extractable=false if they want to forbid extractability, and keep the API working in a predictable manner. Alternately maybe extractable=true should be forbidden during key import. However that feels kludgey in its own way. Other suggestions?
I cannot think of a use case where the ability to do the export of the key for a KDF function is useful. However, I would agree that in this case symmetry makes sense.
Moved to https://github.com/w3c/webcrypto/issues/76