This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The WebIDL for deriveBits reads as: Promise<any> deriveBits(AlgorithmIdentifier algorithm, CryptoKey baseKey, unsigned long length); The "length" argument is not defined as nullable. However there are several of the algorithm's "Derive Bits" reference the possibility of "length" being null. For instance: ECDH: If length is null: Return secret HKDF-CTR: If length is null, then throw a TypeError. PBKDF2: If length is null or is not a multiple of 8, then throw an OperationError. It sounds like the intent was for deriveBits's length to be nullable, in which case it should probably be marked as "unsigned long?" Otherwise as written ECMAScript's ToNumber() will eat the null and spit out a 0, meaning it is only possible for length to be 0 and never null in those sections.
The deriveBits *operation* is also used by the deriveKey method, in which case the length supplied is the output of the 'get length' operation of the target key algorithm. The value null is used for the case where (i) the target key algorithm can import any number of bits and (ii) the derivation algorithm has a default number of bits to output. (i) includes the key derivation algorithms (ii) includes the DH algorithms, where the derived bits are the DH shared secret which has a defined length So, whether the deriveBits *method* supports nullable length is an API design decision. Technically, both options would make sense. [It's still possible there are spec errors - the inconsistency between the returned error types when checking the length value seems wrong].
Thanks for the explanation Mark! Given that when called by derive key it can be null, my bug report is invalid.