This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Currently the supported key lengths for HMAC is left up to implementations. Keys shorter than the blocksize are zero padded by HMAC, and keys longer than the blocksize are hashed. So in theory any key length can be supported by the algorithm. I bring this to your attention because Chromium's implementation currently has an asymmetry in that zero length keys are supported by importKey() but they are not supported by generateKey() (NSS is choking on zero length keys given to "PK11_GenerateKeyPairWithOpFlags"). I can resolve this and consistently support zero-length keys in both functions, or in neither for our implementation. My question is whether this is something that we would want to mention in the spec so that implementations can better inter-operate.
It seems odd to me to require that people do implementation work for a case that likely has no utility (zero length key) and so I'd suggest that we disallow zero-length keys.
In the absence of additional comments, shall we go with my suggestion above to consistently disallow zero-length HMAC keys ?
The specification already returns DataError if the length field if zero on generateKey() or if the length field or actual data is zero length on importKey().