Provides migration from an older, simpler strong name key to a larger key with a stronger hashing algorithm.
Assembly: mscorlib (in mscorlib.dll)
Thetype exposes the following members.
|Equals||Infrastructure. Returns a value that indicates whether this instance is equal to a specified object. (Inherited from Attribute.)|
|GetHashCode||Returns the hash code for this instance. (Inherited from Attribute.)|
|GetType||Gets the Type of the current instance. (Inherited from Object.)|
|IsDefaultAttribute||When overridden in a derived class, indicates whether the value of this instance is the default value for the derived class. (Inherited from Attribute.)|
|Match||When overridden in a derived class, returns a value that indicates whether this instance equals a specified object. (Inherited from Attribute.)|
|ToString||Returns a string that represents the current object. (Inherited from Object.)|
|_Attribute.GetIDsOfNames||Maps a set of names to a corresponding set of dispatch identifiers. (Inherited from Attribute.)|
|_Attribute.GetTypeInfo||Retrieves the type information for an object, which can be used to get the type information for an interface. (Inherited from Attribute.)|
|_Attribute.GetTypeInfoCount||Retrieves the number of type information interfaces that an object provides (either 0 or 1). (Inherited from Attribute.)|
|_Attribute.Invoke||Provides access to properties and methods exposed by an object. (Inherited from Attribute.)|
The new larger key is the signature key. In versions before the .NET Framework 4.5, the signature key was identical to the identity key. Starting with the .NET Framework 4.5, the attribute allows the assembly metadata to continue to have the old public key token and binary large object (BLOB) so that existing assembly references continue to work. It also ensures that the mapping comes from an owner of the identity key.
The presence of the attribute does not necessarily mean that strong name validation takes place. In common full-trust scenarios, the attribute is never considered, because strong name signatures are never validated. However, when the strong name signature does have to be validated, both the strong name signature and the countersignature must be validated. The assembly’s identity key does not have to be identical to the signature key (the key used to do the actual signing and validation). The identity key can be mapped to a different (more robust) signing key. This lets you set the identity of an assembly, and update the signing keys and algorithms to more secure versions.
The countersignature addresses security concerns when a malicious assembly claims some other identity. For example, a malicious System.Core.dll assembly could contain the Microsoft public key in its metadata, and use the attribute to tell strong name validation to use the attacker’s signature key if no countersignature is present. Thus, it could masquerade as a strong name-validated Microsoft assembly.
For information about how to sign assemblies for use with this new attribute, see Enhanced Strong Naming.