Skip to content
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

Add PKCS#11 library support #707

Open
dylrich opened this issue Jun 12, 2024 · 9 comments
Open

Add PKCS#11 library support #707

dylrich opened this issue Jun 12, 2024 · 9 comments
Labels
feature-request help wanted [up-for-grabs] Good issue for external contributors Priority:2 Work that is important, but not critical for the release

Comments

@dylrich
Copy link

dylrich commented Jun 12, 2024

We use this library to sign Nuget packages with certificates stored in Azure Key Vault. However, we'd prefer to not directly talk to Azure Key Vault, but instead use a PKCS#11 library to request signatures from Azure Key Vault. Our PKCS#11 library serves as a standardized authentication and management layer for keys and certificates that we use for other, non-nuget signatures. If this tool supported PKCS#11, we could use this interface for all types of signing. Additionally, it would allow users to sign packages in a wider range of HSM backends beyond just Azure Key Vault, though this isn't the main motivation for us.

Would this project consider accepting a Pull Request that contained a PKCS#11 implementation? It seems like it would need to satisfy these two interfaces if we're reading the code correctly.
@clairernovotny
Copy link
Contributor

Hi @dylrich

We would certainly consider it, can you please provide some additional information about your proposed implementation? We are also refactoring that will make this easier to start once they're merged: #700 & #703

  • Is the implementation entirely managed or is there native code too? If there's native code, what platforms are supported?
  • What are the required parameters needed to configure the provider?
  • Any other details about the implementation? Is it new code or is it coming from an existing source.

@clairernovotny clairernovotny added enhancement Product code improvement that does NOT require public API changes/additions Priority:2 Work that is important, but not critical for the release help wanted [up-for-grabs] Good issue for external contributors labels Jun 12, 2024
@dylrich
Copy link
Author

dylrich commented Jun 13, 2024

Hi @clairernovotny , thanks for the fast response!

We're not sure about the answers to your questions yet and are still working out details about what this might look like. We were mostly curious about if this effort would even be desired upstream! I'll let you know as soon as possible once we have more answers about what exactly we were thinking about.

@dylrich
Copy link
Author

dylrich commented Jun 17, 2024

Hi @clairernovotny,

  1. We were planning on using https://github.com/Pkcs11Interop/Pkcs11Interop to allow talking to unmanaged PKCS#11 libraries.
  2. Users would either need to pass in a PKCS#11 URI and PIN or the path to a PKCS#11 library, key identifier and PIN.
  3. We would write new code to glue this library to the above Pkcs11Interop library

How would you and the team feel about this approach?

@spilkercompra
Copy link
Contributor

We use https://github.com/Pkcs11Interop/Pkcs11Interop.X509Store to talk to a SafeNet eToken and to SoftHSM with this library. For our inhouse use case this is working flawlessly.

@jariq
Copy link

jariq commented Oct 2, 2024

Hello all, author of Pkcs11Interop here 👋🏻

Instead of using complex Pkcs11Interop library which requires strong understanding of underlying standards, I would definitely recommend using more developer friendly Pkcs11Interop.X509Store which provides implementation of System.Security.Cryptography.RSA and System.Security.Cryptography.ECDsa interfaces.

Let me know if you need any help, code review or anything else.

@spilkercompra
Copy link
Contributor

spilkercompra commented Oct 2, 2024 via email

@spilkercompra
Copy link
Contributor

spilkercompra commented Oct 2, 2024 via email

@spilkercompra
Copy link
Contributor

spilkercompra commented Oct 2, 2024 via email

@dtivel dtivel added feature-request and removed enhancement Product code improvement that does NOT require public API changes/additions labels Oct 23, 2024
@dtivel
Copy link
Collaborator

dtivel commented Oct 23, 2024

#639 is the first step in solving this. After that, it would be up to whoever wants to implement a PKCS#11 signature provider for Sign CLI. I don't think there's any work here for Sign CLI beyond implementing #639.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
feature-request help wanted [up-for-grabs] Good issue for external contributors Priority:2 Work that is important, but not critical for the release
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@jariq @clairernovotny @dtivel @dylrich @spilkercompra