Add System.Security.Cryptography.Xml.SignedXml class

[ghost]

Execution plan

Goal: Provide APIs fully compatible with full/Desktop .NET Framework (no changes as part of this work - straight port only)

Plan:

• [x] 1. Add the source code on GH sanitized, with licenses, etc. (it won't build)
• [x] 2. Make the source code build (still excluded from overall repo build)
• [x] 3. Remove Desktop registry-compat code paths
  • Remove methods that have [RegistryPermission] (Utils and SignedXml classes) along with any owned methods
  • Address any other registry-related compile errors such as those using Registry, RegistryPermission, RegistryKey, etc (delete code as necessary)
• [x] 4. Add tests (We have to agree on expected code coverage and how much of the spec we have to cover)
  • Compare test results between Desktop and .NET Core implementations
• [x] 5. Make it part of overall repo build & ship it!

Code changes rules: Only code changes absolutely necessary to make it build and compatible with (full) .NET Framework are allowed, no additional bug fixes or changing architecture - such PRs will be rejected now. Changes like that can be considered after the initial port is done, when we have a good test bed and when we are able to validate such change.

If larger code/architecture changes are needed from some reason, we should discuss them first here, before doing the work / submitting PR.

If you work on some parts of the plan, please say so in the discussion to avoid duplicated work. We (@steveharter @karelz) will co-assign the issue to you.

---

Original

The class to digitally sign XML needs to be added.

[AndersAbel]

@karelz, @steveharter Most registry lookups are located in the Utils class: AllowAmbiguousReferenceTargets, AllowDetachedSignature, RequireNCNameIdentifier. There's also a lookup in the SignedXml class where it setups the list of known transforms. Without the registry compatibility I don't think that the XmlDsigXPathTransform and XmlDsigXsltTransform can be accessed. Should they be removed completely from the source together with the registry-compat code?

That's those I know about, I've not seen any other while reading the code, but I might have missed something.

[steveharter]

@AndersAbel I did update Karel's comment above regarding registry. If there are any classes that are not accessible we need to understand what functionality is being lost. For the ones you mention, I believe CryptoConfig needs to add the name:object pair for those and thus can be created late-bound

[Jaedson33]

When do you think this class will be ready?

[karelz]

Do you mean for contributions? @steveharter plans to submit the initial "add sources" PR very soon (most likely today).

[steveharter]

The initial code has just been merged.

[Jaedson33]

@steveharter Thanks 😃

[karelz]

Thanks @steveharter! I have moved the execution plan to the top-most post for easier progress tracking. Whenever we make changes to it, we will mention the changes in another reply here.

[karelz]

If anyone wants to start working on it, please say so to avoid duplicated work. We will co-assign the issue to you.

[anthonylangsworth]

@karelz: @tintoy and I put our hands up to get started on this. Happy for you to assign it to us.

[tintoy]

If anyone wants to start working on it, please say so to avoid duplicated work. We will co-assign the issue to you.

Cheers - I'm happy to make a start on getting it to compile :)

[tintoy]

@anthonylangsworth - hah, beat me to it!

[tintoy]

Work's happening here.

[karelz]

Assigned to @tintoy. I will co-assign it also to @anthonylangsworth once he accepts the contributor status to the repo (GH won't offer you as assignee option without it).

[tintoy]

Thanks!

[tintoy]

@karelz just to confirm - from what I understand of the contributor guidelines I'm to make these changes in master?

[tintoy]

(my master obviously)

[tintoy]

Ergh, sorry, let me try again - the eventual PR to be against your master?

[karelz]

Yes, that's right. Just don't make it part of full corefx build/test run until the very last phase.

[tintoy]

I've found a couple of constants that seem to have been moved to an internal class in src/Common/src/Interop/Windows/Crypt32/Interop.certificates_types.cs. This isn't accessible from System.Security.Cryptography.Xml though. Any thoughts on the best approach here?

[karelz]

Which of them are needed? All of them? Can you check reference source if they are public in .NET Fx? (I don't think so, but doesn't hurt to double check) I am a bit surprised that we do special interop, instead of leveraging the rest of Crypto library ... either it needs something special, or it is from historical reasons ... @steveharter @bartonjs any thoughts?

[bartonjs]

@tintoy One of the things that needs to be done as this effort is removing the direct interfacing with CAPI, switching to using the .NET APIs.

[tintoy]

@karelz, @bartonjs - mostly CAPI HRESULT constants passed to the CryptographicException constructor.

For example:

src/System.Security.Cryptography.Xml/src/System/Security/Cryptography/Xml/KeyInfoX509Data.cs (line 63)

[tintoy]

I'll have a look at how other code in corefx works with CryptographicException.

[tintoy]

Ah, ok - so it looks like the HRESULT constructor's not used anymore - just the one that takes a message. I'll see if there are existing message resources that correspond to those E_xxx values.

[tintoy]

As for the other issues, it looks to me like a result of types not sharing a single assembly anymore. For example, X509Utils.DecodeHexString is in System.Security.Cryptography.X509Certificates but in the full framework this just lives in the System.Security assembly along with the classes that use it.

Since everything's been broken out into multiple assemblies what's your preferred mechanism for dealing with what would ordinarily be shared components? I could just make a copy of the required functions from code in other assemblies if that's what you'd prefer.

[tintoy]

Or pull in the source using something like:

<Compile Include="$(CommonPath)\Interop\Windows\Crypt32\Interop.certificates_types.cs">
    <Link>Interop\Windows\Crypt32\Interop.certificates_types.cs</Link>
</Compile>

[tintoy]

For now I've worked around the CAPI issue by simply compiling `Interop.certificates_types.cs into the assembly and referencing constants from there.

I also had to copy over some methods from X509Utils.cs in the full framework (mainly to do with Hex encoding / decoding) as there's nothing publicly available in corefx that does this.

The only remaining issues are in src/System.Security.Cryptography.Xml/src/System/Security/Cryptography/Xml/SymmetricKeyWrap.cs (line 34, among others) which result in errors such as:

error CA5350: TripleDESKeyWrapEncrypt uses a weak cryptographic algorithm TripleDES

For now, I've suppressed error. So now it all all compiles :)

Ok, well except for the test project:

corefx\Tools\PackageLibs.targets(34,5): error : Could not locate compile assets for any of the frameworks .NETStandard,Version=v1.7
corefx\Tools\PackageLibs.targets(34,5): error : Could not locate runtime assets for any of the frameworks .NETCoreApp,Version=v1.1

I'll work that out tomorrow.

[tintoy]

@karelz @bartonjs I'm going to open a PR so we can discuss the changes (the work is basically done as far as I can tell) - are you OK with that?

[karelz]

Sounds good to me. @steveharter any thoughts?

[Jaedson33]

Happy new year =D

[Jaedson33]

Do you have any idea when phase 2 will be completed?

[karelz]

dotnet/corefx#14662 is already merged - that was the phase 2. I will mark it in the top post as 'checked'.

[brockallen]

Just so I'm clear: once all 5 steps above are done, then to get ws-fed support in ASP.NET Core, the AAD team needs to do their SAML token bits, then the ASP.NET teams needs to build the ws-fed middleware on the AAD piece. Does that match your expectations?

[karelz]

Nope, this work has nothing to do with WS-Fed. I owe a reply and explanation on https://github.com/AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet/issues/500

[karelz]

FYI: Reply posted: https://github.com/AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet/issues/500#issuecomment-275218749

[Jaedson33]

So when phase 4 will be completed?

[karelz]

If you're asking when .NET team will have time to get to it -- we don't know yet. It is high on our backlog, but there are couple of higher priorities we have to tackle first.

We are open to contributions in the space from the community in the meantime.

[tintoy]

I'm happy to keep working on this, but I'm kinda stuck at the moment; since corefx moved to the new build process, System.Security.Cryptography.Xml no longer builds (so @anthonylangsworth and I are blocked from writing any tests). If we could get just a quick pointer on what's involved in getting the project (and test project) to build, we'll be good to go :)

PS. I've spent 20 minutes or so tracing through the build process to work out why it no longer builds, but haven't worked that out yet. Any pointers would be appreciated...

[karelz]

@mellinoe @weshaggard can you please provide guidance for migrating SignedXml to the new build system?

[Jaedson33]

😭😭 I think I'll need to wait 😭😭

[weshaggard]

@tintoy if you point me at the branch you are currently working on and which project you are trying to build I can help with getting building.

[karelz]

@weshaggard there is currently not a branch - the code is in master, it just is not hooked up into root build (on purpose) - src/System.Security.Cryptography.Xml (introduced in dotnet/corefx#14628). @steveharter can provide additional info.

[tintoy]

@weshaggard @karelz I'm happy to create a branch in our fork and only get it building there to unblock us; later, we can always cherry-pick any changes we've made once it's building again in master. Let me know if this is your preferred approach :)

[weshaggard]

PR https://github.com/dotnet/corefx/pull/15491 should get the project infrastructure working. Once CI passes for it we can merge it and it should bootstrap your efforts.

[tintoy]

Thanks - I've rebased tintoy/corefx/master and will have a play with it shortly :)

[tintoy]

@weshaggard ok, so both src and test project build, but if I add a project reference from the test project to the source project (<ItemGroup><ProjectReference Include="..\src\System.Security.Cryptography.Xml.csproj" /></ItemGroup>), I get:

1>------ Build started: Project: System.Security.Cryptography.Xml, Configuration: Debug Any CPU ------
1>  D:\Development\github\tintoy\corefx\src\System.Security.Cryptography.Xml\src\System.Security.Cryptography.Xml.csproj ConfigurationErrorMessage: Could not find a value for TargetGroup from Configuration 'Debug'.
1>  System.Security.Cryptography.Xml -> D:\Development\github\tintoy\corefx\bin\AnyOS.AnyCPU.Debug\System.Security.Cryptography.Xml\netcoreapp\System.Security.Cryptography.Xml.dll
2>------ Build started: Project: System.Security.Cryptography.Xml.Tests, Configuration: Debug Any CPU ------
2>D:\Development\github\tintoy\corefx\buildvertical.targets(88,5): error MSB4018: The "FindBestConfiguration" task failed unexpectedly.
2>D:\Development\github\tintoy\corefx\buildvertical.targets(88,5): error MSB4018: System.ArgumentException: Property 'ConfigurationGroup' value 'Debug' occured at unexpected position in configuration 'Debug'
2>D:\Development\github\tintoy\corefx\buildvertical.targets(88,5): error MSB4018:    at Microsoft.DotNet.Build.Tasks.ConfigurationFactory.ParseConfiguration(String configurationString, Boolean permitUnknownValues) in D:\Development\github\tintoy\corefx\src\Tools\CoreFx.Tools\Configuration\ConfigurationFactory.cs:line 219
2>D:\Development\github\tintoy\corefx\buildvertical.targets(88,5): error MSB4018:    at Microsoft.DotNet.Build.Tasks.FindBestConfiguration.Execute() in D:\Development\github\tintoy\corefx\src\Tools\CoreFx.Tools\FindBestConfiguration.cs:line 34
2>D:\Development\github\tintoy\corefx\buildvertical.targets(88,5): error MSB4018:    at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
2>D:\Development\github\tintoy\corefx\buildvertical.targets(88,5): error MSB4018:    at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__26.MoveNext()
========== Build: 1 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

I'm guessing I've missed something about how inter-project references are meant to work in corefx?

[weshaggard]

@tintoy I'm not sure what that error is specifically but we generally don't need ProjectReferences in our new engineering system. For the test build we always build and reference the full targeting pack, in this case produced in bin\ref\netcoreapp. The library that is put into that directory is what you build from your ref folder which is currently empty. So to get yourself going you need to generate a ref with the API surface area that you need and get the ref building, then your test project will automatically see the APIs and can build against them. We have a tool called genapi that can generate the ref based on another library. Let me submit another PR quickly to seed that for you guys.

[tintoy]

Ok, now I get it now; the reason I see no types in the test project is because the ref project has no types yet :-)

[tintoy]

@weshaggard if you don't have time, I can probably work out how to do that; I was just reading about that tool the other day.

[weshaggard]

I quickly ran the genapi tool and pushed that commit https://github.com/weshaggard/corefx/commit/29cf289f3e007fd4b13b191866ae848d99dec67e. Feel free to take that or regenerate it yourself. You will need to add ProjectReference's to other refs to get it to compile.