Signing for Windows or macOS

[rjacks24]

I am aware of the discussion on this topic here: #250 (comment),
But as a newb I'm a little unsure about what it all means. That is, I can sign such files, sure, but its cert would not recognized by microsoft as trusted because of the CA, etc and so installation of such would result in the warnings from MS, right?

What I'm trying to figure out though is, provided we are in possession of a cert that is added to their trust stores, would this then allow us to operate our own instance of signstore and fulcio and have it be trusted, or is it that this is still not enough for Microsoft's requirements somehow? I'm just a little fuzzy on what it all means.

We are not prohibited by the cost of certs and we have a cert that is currently in use. Currently we have to use microsoft's signtool and a TA. Can Fulcio / sigstore's stack replace this in any meaningful way if we run it all on-prem? Essentailly it boils down to, we want to have our gitlab pipelines do this work for us and not rely on a special windows VM just for exe and msi files.

@haydentherapper I'd be glad for the "Happy to include documentation in this repo if someone wants to explore how to use Fulcio to sign Windows or macOS apps."

[haydentherapper]

As discussed on that thread, Sigstore certificates will never meet the requirements for EV certificates, as those have particular requirements on the CA that cannot be easily met without significant investment into the management of the CA and ongoing audits, which wouldn't be feasible for an open source project with community-run infrastructure.

I'm fuzzy on the details as I'm not deeply familiar with Windows, but I think you can configure Microsoft's trust store to trust any provided certificate, which could be Sigstore's root certificate. I'm uncertain if you could still get a popup to trust a binary before it runs though - removing that popup needs an EV certificate.

As I mentioned on the linked comment, there are also two or three incompatibilities that aren't possible to work around without using a client that implements Sigstore verification.

1. Sigstore uses TheUpdateFramework to ship its roots of trust. If you manually install the root in a Windows trust store, you won't pick up new roots automatically. This can be worked around with some custom tooling to notify when a new root is available and push it to the trust store (this tooling does not yet exist - it could use a TUF client to periodically download the Sigstore TUF repo and compare the root cert in the repo against what's in a trust store).
2. Sigstore verification requires that clients check a proof of inclusion in the log.
3. This is maybe an incompatibility - you need to provide a signed timestamp to verify short-lived certificates, and it's unclear to me how to do that with Windows and short-lived Fulcio certs.

As I mentioned on the issue, I welcome any documentation on how to set this up with a discussion of the tradeoffs between that and using Sigstore verification tooling.