> …if I choose to sign for TH2, then does that mean the signature
will be good to to that version and the newer ones?
The only known effect that I’m aware of is the OS attribute that gets
created in the .CAT file, which Windows will use to declare whether
the .CAT file is suitable for installation on the running version of
Windows.
For example on a .CAT signed during RS3 release time frame with all
available platforms selected, the .CAT ended up with an OS attribute
of “_v100, _v100_X64, _v100_RS1, _v100_X64_RS1, _v100_RS2,
_v100_X64_RS2, _v100_RS3, _v100_X64_RS3”.
My empirical test was to sign one of our product builds by selecting
only the TH1 1507 platform (OS = “_v100, _v100_X64”), and then
attempting to install the signed product on the then-current RS3
platform. This worked, as expected.
By “as expected” I mean that I expect any version of Windows 10 to
accept a Microsoft-signed driver even if it was only signed and
OS-attributed for a Windows 8.1 or earlier platform; let alone simply
an earlier version of Windows 10 itself. Backwards compatibility
demands that this be true where ever possible.
Neither the HLK process nor the attested signing process require that
we “re-sign and re-publish our drivers every time a new Windows 10
platform is released.” Hence the expectation that signing with only
the oldest TH1 1507 platform would be accepted for all subsequent
platforms, too. Because at some point in the past, TH1 was the only
platform we even COULD select during attested signing, and those
drivers are still able to be installed and used on today’s platforms.
I’m not aware of any compelling reason NOT to select all platforms
you’re compatible with, similar to what Peter recommended. But at
least in my software-only non-PnP driver case, there is no known
benefit to selecting anything other than the oldest platform, either.
Alan Adams
Client for Open Enterprise Server
Micro Focus
xxxxx@microfocus.com