Signing: use separate fallback certificate bundles for code signing and timestamping

[dtivel]

NuGet signed package verification on Linux and macOS uses the fallback certificate bundle that ships in the .NET SDK. Some recent issues have pointed out that this certificate bundle lacks some root certificates and results in "untrusted root" warnings/errors during signed package verification.

A goal of enabling signed package verification on non-Windows platforms is that trust decisions will always be correct. (This has never been a problem on Windows.) Whatever trust anchors we use must be valid for CS and TS. Actually, it's a bit more nuanced in that whatever set of trust anchors we use for purpose X must be valid for purpose X. The set of trust anchors valid for CS and the set of trust anchors valid for TS intersect but do not necessarily overlap. Using a trust anchor that is only valid for TS (or TLS, for that matter) to verify a CS certificate would be incorrect.

The certificate bundle in the .NET SDK is a subset of the Windows CTL that is produced by the Microsoft Trusted Root Program. While the certificate bundle contains root certificates that are valid for CS and TS, it only contains root certificates which are valid for both CS and TS. The bundle does not contain root certificates which are valid for one purpose one but not the other.

We have a plan (no ETA yet) to have separate fallback certificate bundles for CS and TS. Each bundle will contain the complete set of root certificates for that purpose from the Windows CTL.

This change will require modifications to both dotnet/sdk and NuGet/NuGet.Client.

Related:

• Re-enabling signed NuGet package verification
• Re-enabling Cross-Platform NuGet Signed Package Verification Technical Specification

CC @richlander, @aortiz-msft