Quite special PublicKey in .NET core assemblies

That's the ECMA Standard defined public key.

It's to deal with three conflicting requirements:

1. A mechanism that ensures that assemblies are signed by their creators and could not have been created by a fraudulent other party.
2. That CLI be defined openly in such a way that other people are free to implement a version (Mono would be a real-life example).
3. That there be a standard library of classes made available with every version of the framework.

These three things can't happen at the same time!

If I create a version of .NET (point 2), then I need to provide a version of the standard library (point 3), which needs to be trusted (point 1), so I need to sign it to prove that I'm Microsoft. Oh wait, I'm not Microsoft! (eh, point 2 again).

Instead what happens is:

1. I create a public-private key pair. People trusted to build new release versions of the assemblies in my framework library implementation have access to the private key, the public key can be known to anyone doing any work on the CLI implementation.

2. I mark the relevant assemblies as having been signed with the key corresponding to the public key 00000000000000000400000000000000 (defined in the ECMA standard), though really they were signed with the private key mentioned above.

3. In the code in the CLI any check on an assembly that claims to have been signed with the key corresponding to the public key 00000000000000000400000000000000 is checked with the real public key. If this checks out, then it can only have been signed by someone we trust in building those assemblies.

Of course, MS's framework won't trust our assemblies, Mono's won't trust them, and we won't trust either of theirs, because we all have different real keys corresponding to the ECMA standard key. Which is as it should be.

Meanwhile, the fact that 00000000000000000400000000000000 doesn't match any real valid public key means it's not possible for it to clash with any other public key.