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 even to 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 that you want to add Foo Corporation's strong-name public key to your policy. How 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 that you have the signed document, and 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 trustworthy; anyone 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 her to put her imprimatur only on trustworthy authors.

That's what a publisher certificate is like: It not only identifies the author, but also names a trusted authority who attests to the identity and trustworthiness of the author. It indicates details such as who everyone in 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 valid only for a certain period of time, so 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 probably is 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 to 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.

Trusting the CA to make decisions for you, of course, 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 trust only certifying authorities that you believe give out certificates to trustworthy people.

Code-signing certificates, like drivers' licenses, expire after a certain date. And like driver's 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 download recent changes to the revocation lists automatically so that they are less likely to be fooled by untrustworthy individuals who managed to obtain a certificate.

Obtaining Certificates

Suppose that you decide that your customizations should have publisher certificate evidence. Where you get your publisher certificate 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 CA 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 sign a document with a publisher certificate automatically. That's just as well, however. Unlike strong names, publisher certificates have no delay-signing option; 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.

Tip

If you want to provide both strong-name and publisher-certificate evidence for your customization, make sure that the signing authority real-signs the strong name first and then uses signcode.exe to apply your publisher certificate signature to the customization. Both are designed to detect tampering with the assembly, but because both strong-name signing and publisher-certificate signing embed signature information in the document, you may wonder why they do not see each other as tampering with the document. Because the strong-name system was designed after the code-signing system already existed, the strong-name system takes this into account; adding a publisher-certificate signature to a document does not invalidate the strong name.