System.Configuration.RsaProtectedConfigurationProvider depends on System.Security.Cryptography.Xml

[JeremyKuhne]

See dotnet/runtime#14343 and dotnet/runtime#15603.

RsaProtectedConfigurationProvider is the default protected provider and the only one that has a hope of being cross platform. I've ported the code pending the completion of the Xml library- at that point it will just need to be enabled (and tested). For now a stub is in it's place.

[morganbr]

We should consider reviewing the security of RsaProtectedConfigurationProvider and whether it needs to be compatible with files protected by the .NET Framework version as part of this port. That version uses some less-preferred algorithms and may not work cross-platform.

[JeremyKuhne]

@morganbr The only other protected provider in-box (DpapiProtectedConfigurationProvider) only works on Windows. This is more about compat- and I don't see anything existing discouraging use of RsaProtectedConfigurationProvider. Should we be opening an issue (or issues) specifically about discouraging it overall / providing an alternative (on Desktop as well)?

[morganbr]

It's not broken per se, but if we believe desktop config files aren't compatible with .NET Core, it would be good to look into things like using AES by default instead of 3DES.

[danmoseley]

https://apisof.net/catalog/System.Configuration.RsaProtectedConfigurationProvider has negligible usage in our corpuses. https://apisof.net/catalog/System.Configuration.RsaProtectedConfigurationProvider

@JeremyKuhne is it reasonable to move this to Future? cc @krwq

[krwq]

@JeremyKuhne crypto-xml is currently ported - is there anything left for 2.0 here?

[danmoseley]

Crypto XML is not in a net standard configuration right now so this dep is not legal. The usage is so low (zero in our data) that this can be done if and when we get feedback.

[redshiftz]

I work for a government agency and we have been using RsaProtectedConfigurationProvider due to policy requirements by our agency for quite some time. As we're looking at our migration path to .Net Core, this not being implemented is blocking our adoption. Is there a way we can grab what we need and build our own or get this into the roadmap?

Thank you,

Jeff Young

[krwq]

@redshiftz - one way to get unblocked would be to use EnvelopedCms for encrypting data or EncryptedXml for encrypting relevant config file fragment (EnvelopedCms is better from security point of view as it operates directly on bytes and does not perform any further processing. EncryptedXml should be easier to migrate).

Here is what RsaProtectedCofnigurationProvider is doing under the hood: https://referencesource.microsoft.com/#System.Configuration/System/Configuration/RSAProtectedConfigurationProvider.cs,43

As for this thread RsaProtectedConfigurationProvider should not be blocked anymore since EncryptedXml is already here.

I do not know about specific plans for System.Configuration though cc: @AlexGhiondea

[JeremyKuhne]

As for this thread RsaProtectedConfigurationProvider should not be blocked anymore since EncryptedXml is already here.

As @danmosemsft pointed out, EncryptedXml isn't part of .NET Standard so some hoops would have to be jumped through. Not sure if that means adding a CoreApp build for this, another assembly, etc.

[redshiftz]

So, to unblock, would it be reasonable to grab the source of RsaProtectedConfigurationProvider rename to RsaProtectedConfigurationProviderTemp, and build using EncryptedXml? Then change that name in the config file where referenced? Then I can change the config files back if RsaProtectedConfigurationProvider is ever finished?

[krwq]

Since this is legal question I'd prefer @richlander or @immol to answer.

Here is what I know:

• https://referencesource.microsoft.com says "all right reserved".
• I think using samples from documentation is always ok (@mairaw, @rpetrusha could you confirm?)
• almost identical version is here on MIT license: https://github.com/dotnet/corefx/blob/master/src/System.Security.Cryptography.Xml/tests/Samples/EncryptingDecryptingAsymmetric.cs

[redshiftz]

I'm referring to https://github.com/dotnet/corefx/blob/master/src/System.Configuration.ConfigurationManager/src/System/Configuration/RsaProtectedConfigurationProvider.cs

Which says it's under MIT license.

And the code is already written. It's just IFDEFed out.

[redshiftz]

@JeremyKuhne I grabbed your port, uncommented and tried to build. There is another class missing from core that needs to be added to enable this. FipsAwareEncryptedXml (https://referencesource.microsoft.com/#System.Configuration/System/Configuration/FipsAwareEncryptedXml.cs). Once i ported it locally, your port of RsaProtectedConfigurationProvider works.

As @krwq mentioned, there are legal issues to consider since it's MS code. At least for me. What is the path forward do you think?

[krwq]

@redshiftz - I think using EncryptedXml directly should work but not sure if there will be FIPS certification issue there. @bartonjs do you perhaps know if corefx's AesManaged implementation is FIPS certified? If not is it possible to force CryptoConfig to create AesCryptoServiceProvider? (perhaps some magic setting in CryptoConfig)

[bartonjs]

Nothing in .NET Core throws a FIPS exception. All of the types which would have instead are wrappers over FIPSy types.

[spanevin]

Any hope to get it working in netcore?

[hikarunoryoma]

@redshiftz - I think using EncryptedXml directly should work but not sure if there will be FIPS certification issue there. @bartonjs do you perhaps know if corefx's AesManaged implementation is FIPS certified? If not is it possible to force CryptoConfig to create AesCryptoServiceProvider? (perhaps some magic setting in CryptoConfig)

After replacing the usage of FipsAwareEncryptedXml with EncryptedXml, I actually wasn't able to get this to work. I'm getting the error: Failed to decrypt using provider 'ProviderName'. Error message from the provider: Keyset does not exist (Path\to\config line 158). Curious if others were able to get this to work.

Edit: nevermind I figured this out. My issue here was that the credentials I was using to access the secret was different the credentials used to make it. Changing permissions verified that this work around works! Would still have preferred for this to work out of the box, although understand that general industry trend is to move away from RSA Containers.