Publisher Certificates

Strong names, as just described, were invented to solve a particular problem. They provide strong evidence that the code you are loading is the code that you actually intended to load. Because the public key of the author is part of the strong name, you can use strong names as evidence to create policies that grant full trust to code authored by particular trusted individuals or groups.

But then what is a publisher certificate for? What is the difference between signing code with your organization's strong name private key and signing code with your organization's certificate?

You will note that by using strong names as evidence when setting security policy, we are essentially using strong names to do something that they were not designed to do. Strong names were designed to solve the naming problem, not to solve the more difficult problem of codifying trust relationships between code authors and code users.

This is not to say that strong names are not adequate; clearly, strong names are strong enough to use as evidence in security policy. But think about some of the shortcomings of the strong-name system:

• What if disaster strikes and the private key of a trusted author is revealed? There is no standard procedure in place to deal with this. There is no standard way to even publicize that a problem exists!
• The longer a strong name's public key has been public, the longer attackers have had to attempt to determine the corresponding private key through either brute-force or sophisticated cryptographic attacks. But strong name public keys have no standard mechanism for indicating expiry dates or updated keys.
• Suppose you want to add Foo Corporation's strong-name public key to your policy. How exactly do you know that you are adding Foo Corporation's key? If some evil hacker can convince you that his public key is actually Foo's key, you will write a policy that trusts the evil hacker.

Amateur cryptographers often think that coming up with the "unbreakable" algorithm is the hard part. That is hard, no doubt about it. But building a system to manage the keys effectively is often what makes or breaks an implementation. Clearly, strong names do not have a very sophisticated system for managing keys. By contrast, publisher certificates were designed for exactly these scenarios.

License to Code

An analogy might help. Imagine that you are reading a document, and you want to know whether it is factual or full of lies. If the author is trustworthy, you are more likely to believe the document's contentsprovided, of course, that you have reason to believe that the document was in fact by the stated author. Perhaps the author has signed the document and you recognize the signature. The details of how you come to trust the author, how you learn to recognize the signature, and so on are left up to you.

Now suppose you have the signed document, you trust the author, but you do not know what the author's signature looks like. Therefore, you cannot tell whether this document is actually trustworthyanyone could have signed it.

But if in addition you have a notarized statement from the editor-in-chief of the Encarta encyclopedia attesting to the accuracy of the document, that might be enough. The notarized, dated statement describes the document in question, identifies the author, and has a copy of the author's signature for comparison. You do recognize the signature of the editor-in-chief, and trust them to only put their imprimatur on trustworthy authors.

That's what a publisher certificate is like: It not only identifies the author, but it names a trusted authority who attests to the identity and trustworthiness of the author. It indicates details such as who everyone on the "chain of trust" is, when the various certificates identifying them were signed, and so on.

We use certificate-based evidence all the time in real life. A driver's license identifies the bearer by providing a description (name, age, height, weight, eye color, hair color), a photograph, and a signature. It also attests that the individual thereby identified has passed a driving test. To be useful as evidence, the description must match the bearer, and it must have actually been issued by the department of motor vehicles. Furthermore, it is only valid for a certain period of time, so that out-of-date licenses become invalid.

Various organizations that need to determine the trustworthiness of individuals they know nothing about use certificate-based evidence in their policies. If you are trying to get into a bar, any state-issued evidence that indicates your age is probably good enough. If you are trying to rent a car, odds are pretty good that you will need a driver's license, with its further evidence that you passed a driving test at some point. But either way, what is happening here is that organizations are leveraging their trust of one entitythe stateto obtain evidence about the identity and trustworthiness of an unknown individual.

Publisher certificates are essentially licenses to write code, not drive. A publisher certificate identifies a particular author and also identifies the certifying authority (CA), which vouches for the identity and trustworthiness of the author.

Of course, trusting the CA to make decisions for you once more trades convenience for risk. The CA might choose poorly, or fail to exercise due diligence in vetting its authors. You might not agree with the criteria that the CA uses to decide who is trustworthy. In such cases, do not trust the CA! You would not rent a car to a driver who presented a driver's license from Bob's Discount Driver's License Emporium, so only trust certifying authorities that you believe give out certificates to trustworthy people.

Code-signing certificates, like drivers' licenses, expire after a certain date. And, like drivers' licenses, they can be revoked by the CA due to bad behavior. Certifying authorities publish lists of revoked certificates; individuals can configure their computers to automatically download recent changes to the revocation lists so that they are less likely to be fooled by untrustworthy individuals who managed to obtain a certificate.

Obtaining Certificates

Suppose you decide that your customizations should have publisher certificate evidence. Where you get your publisher certificate from depends on how your customers' policies are likely to be configured; obtaining a certificate from a CA that your customers do not trust makes it unlikely that the .NET security system will actually grant full trust to your customization assembly. If you plan on distributing a customization widely to the public, you might consider getting a code-signing certificate from a widely trusted CA such as VeriSign or thawte.

On the other hand, if you are creating a customization to be rolled out inside an enterprise, you can be your own certifying authority by installing Microsoft Certificate Server and issuing your own code-signing certificates to your signing authority.

After you have a code-signing certificate from your CA, you can use the certmgr.exe utility to manage your certificates. Unfortunately, there is no GUI tool in Visual Studio to automatically sign a document with a publisher certificate. However, that's just as well; unlike strong names, there is no "delay-signing" option for publisher certificates; an assembly is either signed with a valid certificate or it is not. Use signcode.exe in the framework SDK directory to attach a publisher certificate to a customization assembly.