AES import operations should store key.[[extractable]]

[BenWiederhake]

For example, consider the AES-CBC "importKey" operation in "raw" format: https://w3c.github.io/webcrypto/#aes-cbc-operations

After creating the key, the [[extractable]] internal slot is never set. In fact, the value of the argument is never even considered, if format is "raw".

However, Chrome and Firefox to seem to read and store this argument:

Suggestion: Change the documentation of the AES-{CTR,CBC,GCM,KW} "importKey" operations to reflect that the [[extractable]] internal slot is set to the given argument.

Found while trying to implement it from scratch.

[BenWiederhake]

Related issue:

• According to the spec, importing a key with empty usages is fine. (In particular, the wording of step 1 of AES-CBC importKey indicates no problem: If usages contains an entry which is not one of "encrypt", "decrypt", "wrapKey" or "unwrapKey", then throw a SyntaxError.)
• However, Chrome and Firefox refuse: Uncaught SyntaxError: Usages cannot be empty when creating a key. and Uncaught (in promise) DOMException: An invalid or illegal string was specified respectively.

Suggestion: Change the documentation of the AES-{CTR,CBC,GCM,KW} "importKey" operations to reflect that empty usages are not permitted.

Btw, is this style of reporting acceptable and useful? My ideal goal is accurate documentation of the actual, interoperable implementations. This is why I'd like to resolve this disagreement between spec and (two of the most popular) implementations.

[panva]

Related issue:

• According to the spec, importing a key with empty usages is fine. (In particular, the wording of step 1 of AES-CBC importKey indicates no problem: If usages contains an entry which is not one of "encrypt", "decrypt", "wrapKey" or "unwrapKey", then throw a SyntaxError.)
• However, Chrome and Firefox refuse: Uncaught SyntaxError: Usages cannot be empty when creating a key. and Uncaught (in promise) DOMException: An invalid or illegal string was specified respectively.

Suggestion: Change the documentation of the AES-{CTR,CBC,GCM,KW} "importKey" operations to reflect that empty usages are not permitted.

Btw, is this style of reporting acceptable and useful? My ideal goal is accurate documentation of the actual, interoperable implementations. This is why I'd like to resolve this disagreement between spec and (two of the most popular) implementations.

This comes from the definition of the method in question, not from the algorithm, namely this text:

If the [[type]] internal slot of result is "secret" or "private" and usages is empty, then throw a SyntaxError.

---

After creating the key, the [[extractable]] internal slot is never set. In fact, the value of the argument is never even considered, if format is "raw".

Very similarly, the [[extractable]] internal slot is being set by the method's definition, not by each individual algorithm.

Set the [[extractable]] internal slot of result to extractable.

[BenWiederhake]

Thank you!

I'm probably missing something very similar, but I don't quite see where [[type]] is being set in the case of AES-CBC? The fact that some other algorithms (e.g. RSA-OAEP importKey) do it, makes me think that AES-CBC importKey should also set its [[type]].

Did I miss yet another page, or is that an actual spec oversight?

[panva]

Did I miss yet another page, or is that an actual spec oversight?

It very well might be, please open an issue for it.