25741 2014-05-16 18:45:23 +0000 RSA-OAEP is under-specified when the parameters define an operation not supported by the key size 2014-10-22 21:03:33 +0000 1 1 1 Unclassified Web Cryptography Web Cryptography API Document unspecified PC Windows NT RESOLVED FIXED P2 normal --- 26903 1 sleevi sleevi public-webcrypto virginie.galindo watsonm oldest_to_newest 106190 0 sleevi 2014-05-16 18:45:23 +0000 With RSA-OAEP, the maximum message size is equivalent to: modulus length - 1 (leading 0x00 octet) - hash size (masked seed) - hash size (lHash portion of the maskedDB) - 1 (at least one octet for the padding string, equal to 0x01) The result of this is that it's possible to specify a set of parameters during an operation that are not supportable by the key. For example, using a 1024-bit key with SHA-512 as the hash algorithm is not possible, because the minimum size of an OAEP encoded message is 1040 bits. The question is whether this should be presented as a DataError (implying implementations may need to do validation prior to the underlying implementation) or left as an OperationError. The spec is unclear on this. In the case of AES-KW, for example, a DataError is raised if plaintext is not a multiple of 64 bits. With RSA-ES, however, which also has a maximum message size (modulus length - 11), no spec-specific behaviour is defined, therefore an OperationError is expected. At least one user agent (Chrome) implemented behaviour that treated RSA-ES message failures as a DataError, assuming the AES-KW behaviour, so the spec should be explicit either way for interoperability. 106191 1 sleevi 2014-05-16 18:46:21 +0000 For what it's worth, my vote is on OperationError consistently for all of these, as otherwise it implies that implementations may need to be redundantly validating the parameters of the underlying implementation. 111950 2 watsonm 2014-09-22 17:50:10 +0000 I agree with normalization to OperationError for all such cases, since the detection of the error may be delegated to cryptographic libraries in some implementations. 112274 3 watsonm 2014-09-26 17:32:06 +0000 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]. 113091 4 virginie.galindo 2014-10-14 10:03:08 +0000 In order to progress towards exit to Last Call for the Web Crypto API, the chair suggests the following resolution for that bug. Resolution : Bug CLOSED. Proposed suggestions made by Mark in https://www.w3.org/Bugs/Public/show_bug.cgi?id=25741#c3 will be implemented. If none objects before the 20th of Oct @20:00 UTC, this resolution will be endorsed. 113266 5 watsonm 2014-10-16 00:43:43 +0000 https://dvcs.w3.org/hg/webcrypto-api/rev/5e7ba79bdf36