This question is an extension of the following:
- Should each project being signed with a separate Strong Name Key (.snk)?
- snk vs. code signing certificate
- Any reason to ship .snk file with the project sources?
- https://docs.microsoft.com/en-us/dotnet/standard/assembly/enhanced-strong-naming
I am looking at Strong Naming a custom assembly along with code signing it and have read various SO posts (see above) and the MSDN. I understand the following:
- Strong naming an assembly without a password creates an SNK file and only identifies the publisher of the assembly so that it can be deployed to the GAC and mitigate the so-call
DLL Hell
caused by identically named assemblies from different publishers. - Strong naming an assembly with a password adds code signing to an assembly and creates a PFX file, instead of an SNK file. This both identifies the publisher and verifies that the code has not been tampered with. Note: This file can either be created, and thus imported, by a trusted certificate authority like Verisign and Digicert or it can be a self-signed certificate created within the organization. Self-creating a PFX is the same step as creating a Strong Named assembly, but you just add a password to it.
- Enhanced Strong Naming seems a bit of a mystery to me. It involves creating a Strong Named SNK file (i.e., no password) and then extracting the private key from it. It seems to only be for allowing the migration from deprecated hashing algorithms.
I understand 2 to be a logical extension of 1. Is my understand above correct? But, what is the difference between 2 and 3 above? Does 3 have any advantage over 1 or is it just a way to allow migration across algorithms only? Said differently, I imagine the 2 and 3 exist for distinct reasons; what is that reason/implementation?