views:

132

answers:

1

In my organization we use snk files with strong names assemblies. We generate the snk ourselves.

In addition we use a code signing signature on the binaries. We get the pfx from Verisign.

  • What is the difference between these two processes?
  • Isn't it a problem that the snk is not recevied from Verisign also?
A: 

The snk and pfx are used for two different purposes. The snk is used for strong-naming, which uses a key pair to uniquely identify an assembly. The pfx is for code signing, which is a similar process but one that is intended to prevent malicious tampering with assemblies that are distributed publicly. Using both on an assembly both strong-names AND signs it.

It's OK to generate your own SNK file as long as you keep the private key secure. The PFX file you get from Verisign allows you to sign the assembly using a key secured by a third party. This is an additional layer of security that lets users of your assembly know that it has not been tampered with.

Dave Swersky
So the snk just binds a private-public key pair to an assembly, regardless of the key owner identity, in order to allow strong reference? This means that if I ( a user) trust the exe I can trust all references. And how would I trust the exe, is it where the code signing comes into place? In this case I should only sign the exe and not the other assemblies because I know they have not been tampered with. Is this correct?
Yaron Naveh
The fundamental difference is that an SNK signing is done by an individual and supports adding an assembly to the GAC. Code signing is mediated by a trusted, bonded third party, as with SSL. The private key is held and the public key published by Verisign (in your case.) In either case, the assembly is "signed" with the private key and validated with the public key.
Dave Swersky
I would say that signing with snk gives assurance of no tampering (by virtue of the hash checks), whereas signing with pfx gives assurance that the code did indeed come from a given source (as verified by Verisign when the certificate was purchased). Moreover (I could be wrong here), I think signing with pfx makes signing with snk superfluous.
Kent Boogaart
Here's confirmation of my previous comment of pfx yielding a superset of snk functionality: http://blogs.msdn.com/b/shawnfa/archive/2006/02/14/531921.aspx
Kent Boogaart
@Kent: Exactly right- code signing adds the security of confirming the source of the code (i.e. Microsoft.) It makes sense that an assembly could be both strongly-named AND signed with the file from the signing authority.
Dave Swersky
@Dave: A code signing certificate ensures both the source of the code and that it was not tampered. Why do we need snk in addition?
Yaron Naveh
@Yaron: You don't need the snk in addition, Kent's link demonstrates that you can apply the pfx *instead* of the snk.
Dave Swersky
@Dave: Developers here are not allowed to have access to the pfx. I guess this is why we use snk in addition. So is the way to go us to use both snk and pfx (I heard something on "delayed signing")?
Yaron Naveh
Delayed signing allows developer groups to work with an assembly as if it were signed. It's probably a good idea to control strong-name signing the same as with code signing, so you might want to look into it. More info: http://msdn.microsoft.com/en-us/library/t07a3dye(VS.80).aspx
Dave Swersky