This is specific to PKCS7/CMS.
See rfc3370 3.2 and rfc5754 3.2,
noting that the referenced versions of PKCS1v2.0 rfc2437 and 2.1 rfc3447 have been formally superseded by 2.2 rfc8017 but the content relevant here hasn't changed. Bear in mind that the original versions of both PKCS1 and PKCS7 (which became CMS) were written in the early 1990s, before it became understood that describing signature and verification as 'encrypting' and 'decrypting' the hash with the private and public keys, or 'backwards', is misleading; PKCS1 is only descriptive has been corrected but PKCS7/CMS has this mistake baked into the ASN.1 and can't be fully corrected without introducing incompatibility.
For "RSA" signature, more exactly RSASSA-PKCS1-v1_5 from PKCS1v2.0 up, with SHA-1 the 'digest' OID is 18.104.22.168.2.26 and the 'signature' OID is 1.2.840.113522.214.171.124. For e.g. SHA-256 they are 2.16.8126.96.36.199.4.2.1 and 1.2.840.1135188.8.131.52. Although represented by two OIDs in different parts of the message, these actually use the standard hash,pad,modexp scheme with only one hash operation. Don't use MD5, it's broken for collision and thus signature in any setting where the adversary can affect the data (e.g. certificates), so as a result people no longer trust it for anything. SHA-1 also is broken (more recently, see other Qs and https://shattered.io) for 'high-resource' attackers like a government or google, and most people have stopped trusting it.