Search code examples
securitycertificate.net-assemblycode-signingstrongname

What is the difference between Enhanced Strong Name (SNK) and Personal Exchange Format (PFX) and when should each be used?


This question is an extension of the following:

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:

  1. 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.
  2. 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.
  3. 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?


Solution

  • Addition to 1: You want strong naming to ensure no unsigned assembly is referenced. You might not want to use the GAC.

    Correction to 2: code signing != strong naming. for strong naming usesn.exe to create a key. For code signing a x.509 Digital certificate with its private key is needed. A certificate itself has no password. The password is used by the PFX/PKCS#12 container format to protect the private key. Other options. like e.g. a smart card or token are possible.

    So 2 is NOT the extension to 1. 3 has the advantage of using better hash algorithms and two instead of one signature.