title: Microsoft MSCAPI-CSP and CNG compatibility
body: <p>We have previously developed an RSA MSCAPI CSP for use with the classical Windows crypto API and this has worked fine for years. Unfortunately, newer versions of Outlook refuse to work with this CSP in the case of AES encryption. It still supports 3DES but not AES. This is quite bizarre because it is actually not the CSP which handles the symmetric decryption, but apparently Microsoft doesn't want to support the AES-case for MS-CAPI. For AES-support, the RSA key needs to be in a newer provider type namely a Key Storage Provider conforming to the CNG framework.
  OK fine, but here's the rub: How can I ensure backwards-compatibility for clients that have software that relies on the MS-CAPI interface?<br>
  According to my understanding (which could be wrong), the certificate store is the same for MSCAPI and CNG. The difference comes in in terms of how the private key is referenced. The certificate has an attribute "CERT_KEY_PROV_INFO_PROP_ID" containing a number of fields including provider name, container name and provider type. If provider type is "0" (which was not a legal value in the old API) it indicates that the provider specified is actually one of the new CNG providers.</p>
  
  <p>An old application will use the values from CERT_KEY_PROV_INFO_PROP_ID to acquire a crypto context using the legacy functions, i.e. CryptAcquireContext().  However, this function fails in the case of a CNG provider (i.e. provider type = 0) - here it seems the program will have to use the new CNG functions i.e. NCryptOpenStorageProvider, NCryptOpenKey etc. again passing in the values from CERT_KEY_PROV_INFO_PROP_ID. So if this understanding/testing is correct it means it is not possible to migrate to a CNG provider and still have the same certificates/keys working from the point-of-view of legacy application programs. I have not been able to find this stated explicitly in the documentation, but it seems each application program which will need to look at the CERT_KEY_PROV_INFO_PROP_ID content, and have a switch: If it is provider type = 0, this is a key in a CNG provider so the program will use the new CNG functions. On the other hand, if provider type is > 0 the program should use the legacy functions. But of course, a legacy program will not have this logic and will thus fail in case of the keys in CNG providers. Meaning it is not possible to satisfy the needs of both new and legacy programs because you have to either put in a reference to a legacy provider og a new provider in CERT_KEY_PROV_INFO_PROP_ID, but you can't have both. And Outlook only wants a reference to a new provider, and old programs can only work with old providers.</p>
  
  <p>But can this really be so, or is there some thing I am missing or some error in my understanding? It seems there would have been multiple ways for Microsoft to help programs have some type of interoperability (for instance so old programs could use the new KSP's using the old API).</p>