Shawn,
I found the following information in http://social.msdn.microsoft.com/Forums/en-US/Geneva/thread/35c10fe5-9693-4f3a-9c5c-8afbb423ee95
For those who were unable to get this problem resolved using Phil Bolduc's solution...
I was having the same problem, and in reading some known issues with the WIF Samples, it seemed that there is a need to run this function in both 64bit and 32 bit mode, as the registry keys injected by this routine seem to be bound to the platform binary.
The solution is to compile both a 64bit executable and a 32bit executable, and run each of them once.
If you want to check that the OIDs have been registered successfully, check the following registry hives:
- 32bit - HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Cryptography\OID\EncodingType 0\CryptDllFindOIDInfo
- 64bit - HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\CryptDllFindOIDInfo
each should contain the 3 OIDs which represent the 3 new SHA2 algorithms
- (SHA256) - "2.16.840.1.101.3.4.2.1!1"
- (SHA384) - "2.16.840.1.101.3.4.2.2!1"
- (SHA512) - "2.16.840.1.101.3.4.2.3!1"
The solution suggests to call Oid2.RegisterSha2OidInformationForRsa(); and I checked the source code of the method which excludes windows 2008 R2. I modified the code to make it do the registration for windows 2008 and did successfully get the
32bit keys registered. However, The 64 bit version wouldn't compile because mscorlib.dll "targets a different processor. Any suggestion on how to register the 64 bit keys?
Come back to the beginning, will registering the 64bit keys resolve the problem?