This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 25741 - RSA-OAEP is under-specified when the parameters define an operation not supported by the key size
Summary: RSA-OAEP is under-specified when the parameters define an operation not suppo...
Status: RESOLVED FIXED
Alias: None
Product: Web Cryptography
Classification: Unclassified
Component: Web Cryptography API Document (show other bugs)
Version: unspecified
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Ryan Sleevi
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 26903
  Show dependency tree / graph
 
Reported: 2014-05-16 18:45 UTC by Ryan Sleevi
Modified: 2014-10-22 21:03 UTC (History)
3 users (show)

See Also:

Attachments

Description Ryan Sleevi 2014-05-16 18:45:23 UTC 
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.
Comment 1 Ryan Sleevi 2014-05-16 18:46:21 UTC 
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.
Comment 2 Mark Watson 2014-09-22 17:50:10 UTC 
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.
Comment 3 Mark Watson 2014-09-26 17:32:06 UTC 
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].
Comment 4 virginie.galindo 2014-10-14 10:03:08 UTC 
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.