Ding-Dong the PIC is Dead
The most startling change in the x64 driver signing program is the total elimination of the Microsoft-issued Publisher Identity Certification (PIC) for signing shipping drivers. In its place, driver developers and publishers will use their Class 3 Code Signing Certificate, along with a new readily available item called a cross certificate, to sign their CATs and x64 kernel-mode executables.

What's a cross certificate? The clearest description I've found was written by Roberta Bragg in her November 2003 editorial on Redmondmag.com titled Cross Certification Trusts.  The way cross certifications will be used for the x64 kernel- mode code signing program is as follows:  there will be one cross certificate issued by Microsoft for each Certificate Authority (CA) whose Class 3 Code Signing Certificates Microsoft trusts for x64 code signing. Because the cross certificate is neither secret nor valuable by itself, Microsoft anticipates making these certificates easily available. For example, they may be downloadable from Microsoft's Web site.

When a driver developer or publisher uses the signtool utility to sign their CAT or x64 executable, they specify both their code signing certificate (issued to the company by one of the trusted CAs) and the cross certificate (issued by Microsoft indicating that the CA is one that is trusted). Changes to the signtool utility were needed to support cross certificates. The new version is available in versions of the WDK starting with build 5370.

The elimination of PICs is sure to make life easier for driver developers and publishers. For one thing, it presumably means that a winqual account is no longer necessary. For another, not having to get a PIC means not having to get somebody at your company to review and sign a Microsoft legal agreement. If you ask me, any time you can avoid getting lawyers involved, you're automatically better off.

More CAs
By itself, simply eliminating PICs isn't likely to satisfy the objections raised by the community to the initial x64 driver signing program. Our previous article indicated one of the biggest problems with the initial program was that the only certificate authority (CA) announced as being "trusted" to issue Class 3 Code Signing Certificates was Verisign. This made it very difficult, if not downright impossible, for small companies in certain parts of the world to get a certificate. An integral part of the revised program is the approval of additional "trusted" CAs. While the final list of trusted CAs was not available when this article was written, the names we've heard mentioned should make it possible for companies, regardless of their size or where they're located, to sign their x64 kernel-mode executables.  We expect the initial list of CAs to be announced by Microsoft at WinHEC. Also, it's important to keep in mind that because of the way the x64 kernel-mode code signing program is structured, Microsoft can add trusted CAs to the list at any time.

Test Signing
Possibly the biggest issue that concerned the community in the initial incarnation of the x64 driver signing program was the lack of any realistic accommodation for testing. The revised program has good news in this area, too. A developer or tester can enable "test signing mode" on a given machine using BCDEdit. Once enabled, this mode will include some visual distinction on the desktop such as that presently provided in safe mode. When in test signing mode, x64 kernel-mode code signing will still be required, but Windows will not check to see if the certificate used to sign the executable is rooted in one of the trusted certificate authorities. This means that even a self-issued certificate created using the WDK's makecert utility will be sufficient to install or load an x64 driver in test mode.

We couldn't be happier with the plan for test signing. It provides significant flexibility to devs and testers while securing the certificate that will ultimately be used for release signing. Once test signing is enabled on the target machine in your office and on the machines in your test lab, you'll be able to sign your x64 kernel-mode executables with any old cert and get on with your testing without further annoyance.

Further, while it falls short of a generic method for bypassing code-signing entirely, turning on test signing at least provides some practical method (beyond hooking-up a debugger and leaving it connected) for a user to load a driver that hasn't been signed with a certificate from a trusted CA. While not perfect, test signing provides a cost-free mechanism that enables users to run community-developed x64 kernel-mode software.

Much Better This Time
This revision of the x64 kernel-mode code signing program sounds much better to us than the program that was initially announced. In summary, the main features of the program are:

• Get a Class 3 Code Signing Certificate from one of the trusted CAs. Microsoft is expected to announce the initial list of these authorities at WinHEC.
• Get the cross certificate that corresponds to the authority that issued your company's Class 3 Code Signing Certificate. This certificate will likely be downloadable from Microsoft.com in the near future. Again, expect more information at WinHEC.
• For testing purposes, enable test mode using BCDEdit. Sign your x64 executables and CAT files using any certificate, even one you create on the spot with the makecert utility.
• For final release signing, use the new version of signtool that is distributed in build 5370 and later of the WDK to sign your x64 executables and CAT files. You must use both your Class 3 Code Signing Certificate and the appropriate cross certificate.

If you just plain hate the idea that the origin of every kernel-mode module has to be identified, then there's not much in this new version of the x64 driver signing program to make you happy. In that case, given that Microsoft has made it clear they consider kernel-mode code signing to be a primary tool in the battle against kernel malware, you've got to either get over it or write software for another operating system.  We're proud of the community for speaking up on this issue, and we're pleased with the revisions to the program designed to address the community's concerns.