Microsoft certs are not by default trusted on Linux/OSX machines. Similarly whatever the trusted root CA is of the authenticode signature is not necesarilly trusted on the host machine.
On OSX, the Mono authenticode implementation uses the shared cert store. By adding the cert to the same store, Authenticode might work OSX.
On Linux there is no unique certificate store.
On Linux, the Mono authenticode implementation uses it's own store. It's more challenging to add the certificate to that store.
dotnet.exe
There is no approach that could work on both Linux and OSX.
Different perspective
We have been thinking about the solutions on a per product level. We can consider a per platform approach.
The issues we have been facing on OSX and Linux can be categorized in 2 buckets.
Trust
Whatever signing approach is used, we need to make sure that the signer chains to a trusted root on that machine.
Microsoft certificates are not trusted by default on either OSX/Linux. There's a Microsoft-wide effort to get our certs trusted on different machines.
This might be years down the line and still wouldn't be completely.
Signature Validation
The NuGet client needs to be able to verify the signature on disk.
Apple Code Signing Services
We can consider using Apple Code Signing, OSX's standard for signing executables.
OSX does not validate the signature prior to execution. We would need to do that manually.
There are ways to validate the signature with Obj C code and/or by invoking additional OSX command.
We need to investigate this approach furher to determine it's viability.
Detached signatures
We can consider detached signatures. Current cryptographic APIs should be sufficient to allow us to verify that signature safely in .NET Core.
This however still doesn't solve the trust problem.
We would need to define our own certicate store/re-use a well known if possible.
If we were to define our own certificate store, we would need to work out a setup story.
Carrying a list of well known certificates would mean we wouldn't do revocation and that could be security risk.
Consider ACS as a valid approach for OSX. Investigate how to do the signature validation and how it plays with Authenticode. Furthemore whatever signing approach we end up doing later for Linux needs to not break ACS/Authenticode scenarios.
Consider whatever the .NET Core runtime comes up with regarding Authenticode like alternatives. That still wouldn't solve the trust problems, so there is no clear direction here.
Consider doing detached signatures and building our signing/verification strategy. This would require a comprehensive design and crypto board reviews.
Open Questions
Can authenticode and ACS live together in the same assembly?
Can we do ACS signature verification from within C#?
What's the progress on Microsoft certs being trusted by default on OSX/Linux?
Which Linux distros are targetted? Timeline?
NuGet.exe on Mono
dotnet.exe
Different perspective
We have been thinking about the solutions on a per product level. We can consider a per platform approach.
The issues we have been facing on OSX and Linux can be categorized in 2 buckets.
Trust Whatever signing approach is used, we need to make sure that the signer chains to a trusted root on that machine. Microsoft certificates are not trusted by default on either OSX/Linux. There's a Microsoft-wide effort to get our certs trusted on different machines. This might be years down the line and still wouldn't be completely.
Signature Validation The NuGet client needs to be able to verify the signature on disk.
Apple Code Signing Services
We can consider using Apple Code Signing, OSX's standard for signing executables. OSX does not validate the signature prior to execution. We would need to do that manually.
There are ways to validate the signature with Obj C code and/or by invoking additional OSX command. We need to investigate this approach furher to determine it's viability.
Detached signatures
We can consider detached signatures. Current cryptographic APIs should be sufficient to allow us to verify that signature safely in .NET Core. This however still doesn't solve the trust problem. We would need to define our own certicate store/re-use a well known if possible. If we were to define our own certificate store, we would need to work out a setup story. Carrying a list of well known certificates would mean we wouldn't do revocation and that could be security risk.
Consider ACS as a valid approach for OSX. Investigate how to do the signature validation and how it plays with Authenticode. Furthemore whatever signing approach we end up doing later for Linux needs to not break ACS/Authenticode scenarios.
Consider whatever the .NET Core runtime comes up with regarding Authenticode like alternatives. That still wouldn't solve the trust problems, so there is no clear direction here.
Consider doing detached signatures and building our signing/verification strategy. This would require a comprehensive design and crypto board reviews.
Open Questions