.NET - Distributing a signed (strong-named) library that depends on an unsigned 3rd party library

I have the following requirements for a .NET library that shall be shipped via NuGet:

• shall be compatible for .NET Framework and .NET Core applications
• shall be signed/strong-named to allow usage in applications that are signed/strong-named on their own

The approach I took for meeting these requirements was to target .NET Standard as target platform, and sign the application. Now the complications started.

There is another library that my library depends on, which is not signed/strong-named (in it's .NET Standard compatible variant). This will lead to a run-time exception like the following:

Unhandled Exception: System.IO.FileLoadException: Could not load file or assembly 'Foo, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. 
A strongly-named assembly is required. (Exception from HRESULT: 0x80131044)

At this point, I see the following options to proceed, but I'm unsure which one to take and whether there's any better way of doing this.

Option 1

Don’t sign the library and leave it to the user of the package to sign the library (along with the dependent library) when necessary. Simple and clean, but creates a lot of effort for developers that rely on a strong-named libraries (e.g. have their own application signed).

Option 2

Create separate projects and NuGet packages for .NET Framework and .NET Core. Strong-name the project/package for .NET Framework, but not the one for .NET Core. Advantage: developers can chose the NuGet package that suits their application’s needs. Disadvantage: creates effort for me as library provider as two projects that are 99% identical have to be maintained in parallel. Also, having two distinct NuGet packages, one for .NET Framework and one for .NET Core seems odd as that is what .NET Standard should be used for instead.

Option 3

Sign both, the library and the dependent library and distribute them together with the same NuGet package. Feasible, but signing a third-party library and distributing it via NuGet sounds “hacky”. Also not sure about the implications if a developer would use a reference to the very same library in a different version and/or an unsigned variant of that very same library.

Any recommendations or other ideas how to solve this situation?