Dotnet-api-docs: SignedCms.ComputeSignature changes

[clairernovotny]

The behavior of the default overload of SignedCms.ComputeSignature(CmsSigner) changed from .NET Framework to .NET Core. In .NET Framework, that would display a PIN prompt if the provider required it. On .NET Core it does not as the silent context is enforced.

Desktop applications should use SignedCms.ComputeSignature(SignedCms, false); to ensure a PIN prompt appears if required. This behavior is the same as on .NET Framework without disabling the silent context.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: f0f19516-254e-d701-1cd3-d2cf4ddac6e5
• Version Independent ID: dc951b71-083e-6127-99a6-e1278ce8c044
• Content: Breaking changes, .NET Framework to .NET Core 3.0 - .NET Core
• Content Source: docs/core/compatibility/framework-core.md
• Product: dotnet-core
• GitHub Login: @gewarren
• Microsoft Alias: mairaw

[krwq]

I can't tell at the moment if this was intentional change or not. Yes, I think we should consider adding back this behavior. @carlossanlop can we move this to corefx?

[clairernovotny]

IIRC, this is intentional. .NET Framework effectively ignored the silent context being set to true (which is the default behavior if you omit the parameter). It always prompted. .NET Core fixed this code path to respect the parameter, so while right, the behavior changes for the user. I believe @bartonjs or @GrabYourPitchforks can confirm.

[krwq]

@onovotny I'll just need clarification from @bartonjs to find if this was intentionally breaking change or because something was not supported when we were porting or some other reason. I can think of some scenarios (servers i.e.) where pop-up might not exactly be expected and this might have been intentional. Note we've done some intentionally breaking changes in i.e. XML we have changed some defaults since they were marked as insecure by multiple security tools - we couldn't previously change them because of the compat concerns (there is still compat concern but it won't break any existing apps until they decide to port to .NET Core)

[bartonjs]

Well it was done as part of the initial bringup of SignedCms on Core (2.1). I don't think we're going to back out the part where we respect a parameter.

It does look like it's only respected when the Windows PAL is used, so Windows OS without using options that force it into the managed PAL (like providing your own private key instance).

[bartonjs]

@carlossanlop @krwq Not a product bug, just a docs bug. Please send it back :)

[carlossanlop]

Sure no problem, @bartonjs.
@onovotny I'll send it to the dotnet/dotnet-api-docs repo, since that's where we host our .NET documentation.

[clairernovotny]

@carlossanlop sure. I was just calling out that it should probably be also on the compatibility differences page that I originally filed this bug against.

Thanks!

[mairaw]

@bartonjs was there any changes done as part of 3.0 that would warrant adding this to the breaking changes page or is this just a change in API docs?

[bartonjs]

Nothing changed in 3.0. It's a platform difference from the beginning of .NET Core's support for SIgnedCms (2.1).