Adding a key to the blockedKeys table is a big action that is both difficult to reverse and can have far-reaching consequences if that key is used by many other certificates, which will then all be revoked by bad-key-revoker. However, adding a key to the blockedKeys table is also an opaque action, since the consequences of it are downstream: bad-key-revoker runs asynchronously.
It would be good for the admin tool to surface potential large-impact key blocks before they're written to the database. This can warn the operator up-front of potential downstream consequences before any real actions are taken.
Note that the admin tool has two codepaths which can block keys: the block-key subcommand, and the revoke-cert subcommand when used with the keyCompromise revocation reason. In the latter case, it's not the admin tool which directly blocks the key, but rather the RA while handling the AdministrativelyRevokeCertificate RPC. These disparate code paths may deserve some unification and some extra safeguards (e.g. a mandatory --block or --no-block flag to the revoke-cert subcommand) as part of this work.
Adding a key to the blockedKeys table is a big action that is both difficult to reverse and can have far-reaching consequences if that key is used by many other certificates, which will then all be revoked by bad-key-revoker. However, adding a key to the blockedKeys table is also an opaque action, since the consequences of it are downstream: bad-key-revoker runs asynchronously.
It would be good for the admin tool to surface potential large-impact key blocks before they're written to the database. This can warn the operator up-front of potential downstream consequences before any real actions are taken.
Note that the admin tool has two codepaths which can block keys: the block-key subcommand, and the revoke-cert subcommand when used with the keyCompromise revocation reason. In the latter case, it's not the admin tool which directly blocks the key, but rather the RA while handling the AdministrativelyRevokeCertificate RPC. These disparate code paths may deserve some unification and some extra safeguards (e.g. a mandatory
--blockor--no-blockflag to the revoke-cert subcommand) as part of this work.