Support PKCS#11 Signing

[garantir-km]

Cosign supports a number of cryptographic signers that witness currently does not. Some examples include Azure Key Vault, PKCS#11, and some hardware tokens. Instead of trying to keep in sync with every signer that cosign supports, is it possible to give the option for witness to make a command line call to cosign for signing with the parameters specified in a configuration file? This way users could configure the cosign call as they desire without witness having to explicitly support each parameter. If this is not possible (or desirable), can support for PKCS#11 be added since it is a generic cryptographic interface (albeit a not-so-modern one)?

[colek42]

I think we would accept PRs for any of these Key Providers, however we are unlikely to shell out to cosign to support additional providers. The community has been working to a unified signer library that multiple projects could use, including cosign and witness. Is there a specific use case you have? I'd like to hear more about your need for PKCS#11.

[ChaosInTheCRD]

Hey @garantir-km, coming here to echo much of what @colek42 said. For the purpose of compatibility/UX/security, we are unlikely to add support for shelling out to other tools as you describe.

Instead of trying to keep in sync with every signer that cosign supports
Given that signing attestations is a key part of our projects functionality, we do indeed aspire to provide all the signing mechanisms that cosign does, which is why as @colek42 specified we are trying to work in the community to create a shared Go library (cosign is also written in Go) for signing logic so that we can all share a well implemented and fully featured signer / verifier interface.

Thanks for opening the issue 😊

[shenke-adsk]

My company uses a commercial code signing solution to manage our signing keys. We do not want users to directly interact with KMS or Key Vault for security/auditing purposes. For such use case, I think it is ideal if PKCS#11 support could be added because it is a common interface. Other code signing solutions such as DigiCert KeyLocker also utilizes PKCS#11.

[garantir-km]

Thank you @colek42 and @ChaosInTheCRD for the quick responses and @shenke-adsk for the support on PKCS#11. I understand that shelling out to cosign is kind of a hacked approach so I see why you would want to avoid it.

What we want to accomplish is similar to what @shenke-adsk described - we want to support generic cryptographic backends without needing custom code. Lots of cryptographic tokens and services (e.g., cloud ones like AWS CloudHSM, Azure Managed and Dedicated HSM, IBM HPCS, etc. and on-premise ones like Luna, nShield, Utimaco, Futurex, etc.) have their own PKCS#11 libraries so being able to use these directly would be great. While a unified signing library sounds interesting, I imagine we would still need to custom code the last mile to plug it to a cryptographic backend, right? Since cosign already supports PKCS#11 would it be a relatively small effort to plug that into witness?

[matglas]

Would it be an idea to rename the issue and focus on PKCS#11 support as a feature request?

[garantir-km]

@matglas Yes, that certainly works for us as all we need is PKCS#11 to have generic support.

[colek42]

We have initial pkcs#11 support in our enterprise version of Witness, but it requires CGO. I think we want to keep upstream pure go right now. We would probably accept a PR that supported PKCS#11 that did not rely on CGO.