Add support for Venafi CodeSign Protect

[zosocanuck]

This PR adds support for Venafi CodeSign Protect.

[ebourg]

Thank you very much for the PR, I'll review it

[ebourg]

Thank you for the quick fixes, but I'm a bit concerned that it doesn't compile. Did you really test it against a real instance of Venafi CodeSign Protect?

[zosocanuck]

I just compiled and packaged and didn't run into any issues, and yes I'm testing in a local development environment against a test instance of Venafi.

[ebourg]

Thank you, there are still some changes necessary but I'll take care of them.

Could you please provide the JSON response to the /vedhsm/api/getobjects request for your RSA test key?

Ideally, if you could import the Jsign test keys and certificates in Venafi and use them to capture the API responses that would be awesome. The keys are in the test resources directory:

RSA: https://github.com/ebourg/jsign/blob/master/jsign-core/src/test/resources/keystores/keystore.p12
EC: https://github.com/ebourg/jsign/blob/master/jsign-core/src/test/resources/keystores/keystore-ec.p12

The password is "password".

[ebourg]

Alternatively, do you think I could access a Venafi test environment?

[zosocanuck]

Here is the vedhsm/api/getobjects response for the test RSA key.
venafi-rsa-getobjects.json

[zosocanuck]

Let me know what else is missing or any other tests that need to be added and I'll get it done 😃

[zosocanuck]

@ebourg just curious if there was anything missing or requires an update.

[ebourg]

@zosocanuck The application id "VenafiCodeSignClient" is hardcoded in the VenafiCredentials class. Shouldn't this be user configurable? For example with an extra parameter to the storepass parameter, something like this:

 jsign --storetype VENAFI \
       --keystore https://example.tpp.local \
       --storepass "<application>|<username>|<password>" \
       --alias my-certificate-label \
       application.exe

[zosocanuck]

@ebourg I was trying to balance the amount of configuration with out-of-the-box defaults in the Venafi platform so that is why this is hardcoded. This is a standard client ID that ships with the product and there is a preference to avoid the customization of API integration client IDs for code signing. My preference is to keep as is.