Strict Microsoft package signature validation

Description of the new feature/enhancement

winget currently makes no distinction between packages provided by Microsoft and community packages, such that there is no way to install Microsoft software that is not shipped in-box like Windows Admin Center or PowerShell 7 with a guarantee that everything downloaded and executed was exclusively signed by Microsoft. The idea would be to make enforcement of signature validation tied to a specific vendor like Microsoft when installing packages: when installing WAC or PowerShell 7, one would have the same kind of guarantee of origin one would expect from Windows Update. A Microsoft package not signed by Microsoft would fail to install.

Proposed technical implementation details

The vendor signature enforcement could be controlled by command-line options, but my recommendation would be to enable it by default for official Microsoft packages, with the Microsoft key pair or certificate trusted by default. This is very similar to how Linux package repositories work (https://docs.microsoft.com/en-us/powershell/scripting/install/installing-powershell-core-on-linux?view=powershell-7.1#ubuntu-1804).

As for the signature mechanism, the most important part is to sign the manifest file. Yes, the manifest contains CDN URLs and the hash of the files, but it's not of much use if the manifest is unsigned because it could be tampered with. A relatively simple way to implement this today would be to borrow the same kind of signature down with OCI artifacts and containers using cosign from the sigstore project: https://github.com/sigstore/cosign

This issue is related to https://github.com/microsoft/winget-cli/issues/702 because it intends to meet the recurring demand for including out-of-box Microsoft software like WAC and PowerShell 7 in-box. I believe that if we provide a fully trusted way to install additional out-of-box Microsoft software without relying on community packages, this demand would be met. If winget can enforce proper trust of origin on Microsoft software, then it's not that much different from calling Install-WindowsFeature. It would be a trustworthy option, rather than simply a convenient option.

The issue names the winget CLI, package manifests, and signature validation but no files, tests, or entry points. Start by locating manifest verification and package-install trust handling, then determine the supported signing and key-trust design before defining tests for rejecting packages without valid Microsoft signatures.