I wrote:
Well, there are three major protocols which use HMAC, namely IPsec, SSL/TLS,
and SSHv2 (aka "SSL done with SSH packet formats"). If macSize is the size of
the generated MAC (128 bits for HMAC-MD5, 160 bits for HMAC-SHA) then SSL uses
a key of size macSize, SSHv2 uses a key of size macSize, and I dunno about
IPsec (the RFCs are silent on this, and I've never implemented it so I don't
know what people use).
Before this ends up in a spec somewhere as "Anyone who doesn't use a <macSize>
key will be banished to van Diemens Land with only an ASN.1 dump for
companionship", does it actually matter what key size you use? Since you can
wrap arbitrary-length keys, you could certainly include an implementation note
to say that the convention is to use keys of size <macSize>, but there's
nothing to prevent you from using keys of other lengths (the SSHv2 spec
actually requires the use of 128-bit keys, but I guess the <SSH-the-company>
implementation used 160-bit keys and everyone copied that). In fact the only
reason that SSL/TLS and SSHv2 specify a size is because their key derivation
process performed after the key exchange part of the protocol handshake
generates a whole pile of keying material and it's necessary to fix where one
key stops and the next one starts. This isn't an issue with CMS.
In fact if you're using a 128-bit AES key from (say) a KeyTransRecipientInfo to
MAC and encrypt you'd use 128 bits, if you're using a 3DES key it's your choice
between 160 and 192 bits, if all you've got is 64 bits you'd use that. There's
no reason to restrict the choice, particularly since you can't control where
the keying material is coming from.
(Just looking at my own code, I use 128-bit keys for all the HMACs if the user
doesn't specify otherwise, mostly because it's "the standard", but they can
specify anything from 40 to INT_MAX or thereabouts if they want and it still
works).
Peter.