Security of using key size larger than the message digest size in HMAC, with one time pads

I would like to know the security of using key size that is larger than the message digest (output) of a HMAC in one time pad encryption. One time pads for the message and the key of HMAC are different, scenario:

• A single message will be sent from A to B on insecure medium but is not known WHEN, in advance.
• Both A and B agreed previously on the one-time pads (which are randomly generated) for the key of the HMAC, and for the message encryption of the message.
• The message M of size L(> 50 bytes, padded) is encrypted with one-time pad of L bytes.
• The key for the HMAC of message digest of size D bytes is a one-time pad and larger than D bytes.
• HMAC uses encrypt-then-mac, so the MAC is HMAC(K, C), where K is the key and C is the ciphertext. Needless to say that one-time pads for the message and the key of HMAC are only used once for this message only.

Because the key size is larger than the output of the hash, can I say that a possible attacker will find the wrong key even if he tries to brute force it? So even if he finds a key, there is a high chance (as the input space "key" is larger than the output space "digest") that he finds it wrong and will be noticed by the recipient when he tries to send a crafted packet.

Is there somewhere that I miss? The one issue that I see here is my doubt of the hash function not mapping inputs to outputs "perfectly" (like the input size of CN not mapping to the output size of N, where each output is mapped to C inputs exactly).

Addressing problems with OTP for HMAC:-

Your construction does not have two factor authentication and that’s poor form with OTPs. All OTP material has to be stored (what you have). If it’s also used for authentication, it’s stored too (what you have). There is no opportunity for authentication via what you know. Thus if I somehow access your key store, I can become you.

I suggest these problems swamp the issue of ”key size is larger than the output of the hash.” Mitigation can be had by exploring your faith in NSA, NIST, Quora, this and other forums and academic papers. Some say that contemporary hash functions used for HMACs are secure. If you believe so, a key correctly derived from a password would create exactly the same security level as current protocols like AES + HMAC. And that would provide two factor authentication. If not, it would be interesting to see reasoned arguments dissuading simple use of any CRC/hash function masked by OTP material.