Emmanuel Bourg

I think I prefer the API integration, PKCS#11 is a pain to use. I got a look at the documentation, the REST API seems pretty straightforward: https://docs.venafi.com/Docs/24.1API/#?route=post-/vedhsm/api/sign

If you want to implement it I can guide you through the process. There are several examples in the jsign-crypto module. Otherwise I'd need a temporary access to a CodeSign...

I've implemented a new signing service for SignPath (5a4418562414dd71080d0ee74c59c95e135dcd4c), you can use this commit as a template for CodeSign Protect.

I like this idea. If we follow this path I'd push further and fully modularize commons-compress, with a separate module for each compression and archive format. That may be easier...

Thank you for the PR, I've made a similar refactoring on a local branch but I was moderately satisfied with the result because many internal details leak in the public...

My concern is mostly the KeyStoreType private methods that become public (`reuseKeyStorePassword()`, `hasCertificate()`, etc). I hoped I could keep these under the rug :)

> You now have classes in net.jsign package in jsign-crypto and jsign-core which is bad for JPMS compatibility as there such split packages are not allowed. Yes I'm aware of...

I've updated my refactoring to use a SPI for the keystores and pushed it to the [keystore-spi](https://github.com/ebourg/jsign/tree/keystore-spi) branch: * KeyStoreType becomes an interface but retains the same fields and methods...

It's possible to workaround the issue by replacing `-SNAPSHOT` with `.SNAPSHOT`: ``` ```

Signing before getting the certificate? I have to think about it, but that's probably difficult because knowing the key algorithm is required beforehand and the certificate is a convenient way...