My company makes a measurement device that connects to the PC via USB and used to use the Windows in-box USB HID driver. I'm using a different driver now to control the device and I am in the process of signing these drivers for many Windows versions. The reason being we want our customers to be able to install our measurement software (which would pre-install these new drivers), plug in our measurement device, and have Windows trust and use our new driver in favor of the in-box USB HID driver. It would also have the added benefit of using this new driver each time the device is connected no matter what USB port is used or if the user connects a unit that has a different serial number in the descriptor.
I've read through and performed the steps outlined in the KMCS_Walkthrough written by Microsoft to perform Test Signing of this driver by creating a catalog file for Windows 7 x64 from the inf file and signing the catalog file with a self-signed certificate. Things seemed to work smoothly on a Windows 7 x64 machine when rebooted into Test Mode. What surprised me was that I was able to create an XP_x86 catalog file, sign it with my test certificate, import my test certificate into the Trusted Root store and get the driver behavior I wanted on a Windows XP machine. The default driver signing policy was set to the default (Warn - Prompt me each time to choose an action).
I'm surprised because all of the MSDN documentation I have been reading about signing drivers for public release for XP seems to have a strict stance on the drivers being WHQL certified in order for the drivers to be fully trusted as opposed to obtaining a code-signing certificate from a third party and using that to sign the driver. Is this not true? How could my self-signed drivers out-rank the in-box USB HID driver in Windows XP?
After A LOT more trial, error, and research, I've finally come to a conclusion.
The key in my initial question was that I was using a self-signed certificate. I generated the self-signed certificate in Windows using makcert and following the example in the KMCS_Walkthrough:
makecert -r -pe -ss PrivateStore -n CN=CompanyName MyCertificate.cer
The parameter which specifies what Enhanced Key Usages (EKUs) the certificate should be valid for (-eku) is not included. What I didn't know was that with this parameter missing, this creates a self-signed certificate with ALL EKUs. Most notably the EKU called "Windows System Component Verification (1.3.6.1.4.1.311.10.3.6)". This EKU is included in certificates for WHQL signing.
So, in fact, Windows XP was behaving appropriately. My driver was indeed WHQL signed, it was just a self-signed WHQL certificate that was used.