- From: <bugzilla@jessica.w3.org>
- Date: Fri, 26 Sep 2014 17:32:06 +0000
- To: public-webcrypto@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25741 --- Comment #3 from Mark Watson <watsonm@netflix.com> --- The following are the instances of explicit operation parameter validation currently in the specification: - AES-CTR encrypt/decrypt: check counter length -> SyntaxError - AES-CTR generate: check key length -> SyntaxError - AES-CTR encrypt/decrypt: check length of counter bits -> SyntaxError - AES-CBC encrypt/decrypt: check IV length -> SyntaxError - AES-CBC generate: check key length -> SyntaxError - AES-GCM encrypt: check plaintext length -> DataError - AES-GCM encrypt/decrypt: check IV length -> DataError - AES-GCM encrypt/decrypt: check additional data length -> DataError - AES-GCM encrypt/decrypt: check tag length -> DataError - AES-GCM generate: check key length -> DataError - AES-CMAC sign/verify: check MAC length -> SyntaxError - AES-CMAC generate: check key length -> SyntaxError - AES-CFB encrypt/decrypt: check IV length -> DataError - AES-CFB generate: check key length -> SyntaxError - AES-KW wrap: check plaintext length -> DataError - AES-KW generate: check key length -> SyntaxError - HMAC generate: check key length is non-zero -> DataError - HKDF derive: check length is not null -> SyntaxError - PBKDF2 derive: check length -> SyntaxError I suggest we leave these checks in the specification, but change them all to OperationError. We therefore leave it to implementors whether the check is done inside or outside whatever cryptographic library is being used. [I don't think it would be a good idea to remove the checks without checking first that the same checks are indeed specified in all the referenced specifications. Otherwise we may have a situation where behaviour is undefined]. -- You are receiving this mail because: You are on the CC list for the bug.
Received on Friday, 26 September 2014 17:32:07 UTC