OK, so it is a standard, in that its defined in SSL and TLS but its certainly not typical.
This comes up every few months for some reason or another, usually folks providing general purpose crypto products who are integrating them with Windows end up being surprised by this, after all this is the most widely used crypto protocol on the planet.
The surprise, to a great extent, comes because people providing general propose crypto implementations in general have the luxury not to worry about the needs of individual products and protocols.
This is why its important they try to replace as little as possible when extending the platform, there are lots of application assumptions that may not be directly obvious to someone plugging in at such a low level.
This is one of the reasons I discourage the development of Cryptographic Service Providers for Smart Cards and instead ask folks to develop Smart Card Mini-Drivers Instead. We have a certification program for these mini-drivers that simulate real world application calling behaviors (like this one) so that these folks can get an idea of if their providers will work with given application scenarios (amongst other things).
But back to the post I was originally going to make, the algorithm used by SSL3 and TLS1 is is basically just a concatenation of the output from a MD5 and SHA1 represented as a a 36 byte value.
Since the SSL/TLS standard said nothing about specifying an OID Windows did not either, instead CryptoAPI1 defined an alg_id (CALG_SSL3_SHAMD5) which is an internal construct used to address the need of plug-able crypto components to communicate what algorithm to use across layers.
In general in such a situation a platform component has a handful of choices of how to deal with this problem, it can assume a provider knows this implicitly (a default), contextually (a default for a given caller) or explicitly (define its own construct to specify the algorithm).
As I said, in the case of CryptoAPI1 the explicit approach was taken and a constant of CALG_SSL3_SHAMD5 was defined for this algorithm, a "Cryptographic Service Provider" would take the handle to the the hash object and use that to determine appropriate OIDs for the underlying calls necessary to get this value.
CNG is a bit different, here there is a API called NCryptSignHash which basically only takes the hash in a memory buffer, this means that it has insufficient information to do this automatic detection and it has to rely on the underlying crypto implementation to figure this out implicitly or contextually.
This is really a artifact of the modularity of CNG, in CryptoAPI1 there was a single monolithic provider you could not really mix and match, this mean the crypto provider had more context so the underlying crypto implementation did not have to worry about this stuff.
The net of all of this is that in the case of CNG a Smart Card Mini-Driver and/or KSP (for example one for a Hardware Security Module) need to deal with this problem directly, as the higher level abstractions can not figure this out for them.