@“Peter_Viscarola_(OSR)” said:
I suspect the CAT isn’t used on Win7, however, because on Win7 I can edit the INF file on the target install system, and the driver still installs without error.
That certainly would seem unusual, since neither actual WHQL signed packages nor cross-signed packages have worked that way on Windows 7 platform previously. Meaning you do get the angry red “installation set has been tampered with” warning when modifying the .INF away from the content it was signed with, which confirms both the .CAT and the contained hash for the .INF file were being verified.
I modified our signing process to no longer pre-sign the binaries with our company code signing certificate, such that only the Attested signing signatures would be present on the binaries. For what it’s worth, neither the “.CAT isn’t used on Win7” assertion, nor the “Attested package installs without error if you didn’t pre-sign the binaries” assertion held true in testing here.
Your expectation regarding the OS attribute list in the .CAT was correct, and by selecting all non-ARM64 platforms during attested signing, the .CAT we received only contains the Windows 10 platforms. Which was the same as what we receive when we do pre-sign the binaries:
_v100,_v100_X64,_v100_RS1,_v100_X64_RS1,_v100_RS2,_v100_X64_RS2,_v100_RS3,_v100_X64_RS3,_v100_RS4,_v100_X64_RS4,_v100_RS5,_v100_X64_RS5,_v100_19H1,_v100_X64_19H1,_v100_Vb,_v100_X64_Vb
But on a Windows 7 Professional x64 machine up to date with SHA-2 support, with this Microsoft Attestation-only signed package I get the “Windows can’t verify the publisher of this driver software” as the interactive angry red publisher verification message. The setupapi.dev.log confirms during _VERIFY_FILE_SIGNATURE that its attempt to verify the .INF file is what failed:
Verifying file against specific (valid) catalog failed! (0xe0000244)
“Error 0xe0000244: This software was tested for compliance with Windows Logon requirements on a different version of Windows, and may not be compatible with this version” as the reason the publisher verification failure was presented.
I’m not a hardware driver, though. This is for a NetClient-class component being installed through INetCfg/NetSetup. So maybe that’s enough to explain the split in the observations. But “signing of driver package for hardware drivers is ignored” still seems like a highly unusual proposition to accept. Maybe knowing what setupapi.dev.log revealed during these multiple successful verifications of the behavior might work toward explaining it, too.