Why Strong Naming?


More from inside the walls:


Q: Does anyone know why we’ve created
two ways to sign the components? The certificate form covers all the needs I can
see. I wonder why we have a separate “strong naming” manner to do signing that
doesn’t cover all the security issues. It seems like both could easily be
covered by using the private key from the certificate. Am I missing something?


A: (from the Security PM on the CLR team)
Strong names were originally
designed for use by our loader to


a) establish assembly integrity (bits haven’t changed since last signing) b)
to enable a cryptographically strong assembly identity for following assembly
references.


It is true that the key pair of a cert could have been used for this as well,
however, we did not think it appropriate to have to require every developer for
the .net framework to own their own certificates. Furthermore, if the same
development shop wishes to create multiple publisher identities, they might have
needed to get multiple certificates.  Also strong names are more light
weight – no revocation checks are performed, there is no trust UI popped to the
user by virtue of an executable just being signed by a strong
name.

Skip to main content