Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Signed CMS for SLH-DSA #115310

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
wants to merge 9 commits into
base: main
Choose a base branch
from
Open

Signed CMS for SLH-DSA #115310

wants to merge 9 commits into from
+2,085 −456

Conversation

PranavSenthilnathan
Copy link
Member

@PranavSenthilnathan PranavSenthilnathan commented May 5, 2025 •
edited
Loading

This PR forks Sign and Verify into a Pure and Hash mode with the Hash mode being the same as the existing implementation. Additionally it adds support for SHAKE128 and SHAKE256 as digest algorithms in CMS.

Some design decisions:

  • The SLH-DSA CMS spec says that the content-type attribute MUST be present for for SLH-DSA. However for counter-signing , RFC 5652 says that counter-signers must not have a content-type attribute. This PR follows RFC 5652.
  • When SubjectIdentifierType.NoSignature is specified, we will check whether the signing algorithm is SLH-DSA and throw if it is. Otherwise we will just use the hash as the signature as before. If Windows has a different behavior for NetFx, we will just adopt it since we don't have an opinion here.
  • Same policy for CheckHash.
  • It's up to the user to specify and/or check the digest algorithm. We do not place any restrictions on hash strength during signing or verification.
  • NetFx public API stays the same and new APIs are added for .NET and netstandard2.1. OpenSsl cannot be supported downlevel but Windows will likely be. This depends on the cert accessors in Microsoft.Bcl.Cryptography which in turn depends on the Windows PQC APIs, so it is not implemented yet.

CMS for SLH-DSA successfully roundtrips with openssl (message created with SignedCms can be verified with OpenSsl and vice versa).

@PranavSenthilnathan PranavSenthilnathan self-assigned this May 5, 2025
@ghost
Copy link

ghost commented May 5, 2025

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

1 similar comment
@ghost
Copy link

ghost commented May 5, 2025

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

@dotnet-policy-service Dotnet Policy Service
Copy link
Contributor

Tagging subscribers to this area: @dotnet/area-system-security, @bartonjs, @vcsjones
See info in area-owners.md if you want to be subscribed.

@vcsjones
Copy link
Member

vcsjones commented May 5, 2025

Are we going to support NET Framework?

SignedCms and all of its associated types type-forward to the .NET Framework implementation. We can't enable it on .NET Framework through System.Security.Cryptography.Pkcs. Whatever work that needs to be done (if any) will need to be done in .NET Framework itself.

runtime/src/libraries/System.Security.Cryptography.Pkcs/ref/System.Security.Cryptography.Pkcs.netframework.cs

Line 33 in 86949c2

[assembly: TypeForwardedTo(typeof(System.Security.Cryptography.Pkcs.SignedCms))]

@vcsjones
Copy link
Member

vcsjones commented May 5, 2025

I am curious if we need to implement any of this down level, since .NET Framework will have its own implementation.

I... think... it probably could make sense to implement all of the new public API surface as #if NET10_0_OR_GREATER and don't implement it down level at all.

  1. >= net462 TFMs are going to get type-forwarded.
  2. <= net9.0 TFMs won't have the new public API. That's okay, they should just move to .NET 10. .NET (Core) users should expect to require updating to get new capabilities.
  3. >= netstandard2.0 this is where... maybe... there is value in doing the OOB. If someone is on netstandard and on Windows, but not .NET Framework and not .NET Core, then down level support might be justified. The one that has come up in the past is UWP.

This was referenced May 5, 2025
Open
Open
bartonjs
bartonjs reviewed May 5, 2025
View reviewed changes
@PranavSenthilnathan
Copy link
Member Author

  1. <= net9.0 TFMs won't have the new public API. That's okay, they should just move to .NET 10. .NET (Core) users should expect to require updating to get new capabilities.

For Unix, downlevel won't work because we don't have the key accessors on certs for openssl in Microsoft.Bcl.Cryptography. However, I think we can still support Windows downlevel (net8.0 and net9.0) since the accessors will be available for them.

  1. >= netstandard2.0 this is where... maybe... there is value in doing the OOB. If someone is on netstandard and on Windows, but not .NET Framework and not .NET Core, then down level support might be justified. The one that has come up in the past is UWP.

After talking to @bartonjs about this: netstandard2.0 should have the same API as NetFx so that means no public API changes. I think netstandard2.1 is more at our discretion and I just added the public API for now.

@PranavSenthilnathan PranavSenthilnathan changed the title Initial draft of signed CMS for SLH-DSA Signed CMS for SLH-DSA May 7, 2025
@PranavSenthilnathan PranavSenthilnathan marked this pull request as ready for review May 7, 2025 21:23
This was referenced May 8, 2025
Open
Open
Open
This was referenced May 8, 2025
Open
Open
vcsjones
vcsjones reviewed May 8, 2025
View reviewed changes
...ryptography/src/System/Security/Cryptography/X509Certificates/X509CertificateKeyAccessors.cs
/// <summary>
/// Helper methods to access keys on <see cref="X509Certificate2"/>.
/// </summary>
public static class X509CertificateKeyAccessors
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we should EB-Never this for .NET 10+?

bartonjs
bartonjs reviewed May 8, 2025
View reviewed changes
This was referenced May 9, 2025
Open
Open
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@vcsjones vcsjones vcsjones left review comments

@bartonjs bartonjs bartonjs left review comments

At least 1 approving review is required to merge this pull request.

Assignees

@PranavSenthilnathan PranavSenthilnathan

Labels
area-System.Security new-api-needs-documentation
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@PranavSenthilnathan @vcsjones @bartonjs