latchset / kryoptic

a pkcs#11 software token written in Rust
GNU General Public License v3.0
10 stars 4 forks source link

RFE: provide a command-line utility to manage tokens #101

Closed rcritten closed 1 week ago

rcritten commented 1 week ago

I currently use opensc pkcs11-tool to manage tokens but I find it cumbersome. Even a think wrapper around it would be better so at least we wouldn't have to always specify the module.

Creating tokens in particular requires two steps. It would be convenient to do it all at once.

If it were also in Rust then it would benefit from using the same find_conf() and display information about what configuration file will be used in the current context.

The output of the pkcs11-tool is nice but it has a bazillion options. It might be nice to have something a bit more user-friendly.

softhsm2 provides a utility which is somewhat usable though I'm not sure I'd recommend it as a model.

I think the necessary options might be to list, remove and delete tokens. list slots and list objects (maybe per-slot).

It isn't clear how a slot is created in kryoptic. Whether a user can provide their own slot id, what happens if it conflicts with an existing one, or one specifies slot 999 as the the first slot.

simo5 commented 1 week ago

We may re-evaluate this at a later time, but one of the goals we had was to avoid re-inventing all the tooling unless necessary. I am afraid a tool would initially be simple (and not super useful) and evolve into a monster like pkcs11-tool unless there is a clear line we do not cross. Do you have suggestions on what options you would retain and what you would not implement compared to pkcs11-tool?

rcritten commented 1 week ago

We are in agreement on adding yet another tool. I was very reluctant to file this.

So the big driver behind this was being able to delete a token. There is no option that I know of in pkcs11-tool to completely delete a token, just individual objects.

We can use certutil -F to remove the private keys and certificates and leave an empty token. That would be similar to what we do with hardware HSMs. It is just an additional, perhaps unnecessary step, for a software HSM dropping a token I think is a lot easier. With softhsm2 for example removing a directory will drop a token.

The motivation for the request was that PKI will re-use private keys if they are present and I had seen failures on hardware HSMs when trying this.

I just tested this with both kryoptic and softhsm2 and both can successfully re-use existing private keys and replace the certificates on an install, uninstall, install sequence of IPA.

I think there may still be value in being able to start over a token from scratch without removing the token db. I'm not too particular about the method.

The two-step process of creating a token with the SO pin and the user pin I think can be confusing for users but I don't see it as a blocker. This request was mostly about being able to fully delete a token.

simo5 commented 1 week ago

There is a PKCS#11 call that should have the effect of completely resetting a token, but I do not know if I implement it fully yet. For kryoptic if you delete the sql file you effectively delete the token and the file will be recreated on (re)initialization.

rcritten commented 1 week ago

I'm just thinking broadly if there are multiple tokens in the same db file and you want to remove one and preserve the others then it could be difficult to manage.

simo5 commented 1 week ago

only one token per db file, this is enforced everywhere atm, ie you need to provide a new file to add a new token to a new slot.

rcritten commented 1 week ago

Ok I didn't make that connection. I think we can close this. The config file change should help here since just zapping the db will remove the token.

simo5 commented 1 week ago

Ok, closing for now, we'll revisit this topic in future if more need arises