Vault should allow to verify all unseal keys

[torinthiel]

Is your feature request related to a problem? Please describe.
Currently after initializing vault it is not possible to ensure that all shares were successfully transmitted to related parties. Only a partial verification is performed, that a threshold of keys were properly transmitted, in a form of a successful unseal operation (if this is done after the distribution and not at the point of initialization). A similar situation occurs for rekey - by default no validation is performed, however a validation of a threshold of keys is possible with the verify enabled.

Describe the solution you'd like
A way to validate that all unseal keys generated after an init or rekey operation are properly stored and accessible, including (in case when PGP encryption is used) that operators are able to decrypt the secrets.

This could be either an additional option to the init or rekey -verify operation, specifying a required threshold for this operation only. This parameter can increase the threshold, but not decrease it.

Alternatively a separate command (operator verify maybe?) could be introduced that follows similar pattern to existing init/rekey/generate-root operations (only one possible at a time, nonce required for updating progress). This operation would take as an argument required threshold (no less than the standard one) and on giving required number of shares would verify that all given shares consistently recover the same secret.

Describe alternatives you've considered
The vault operator rekey -verify option provides a subset of needed functionality.

With some prior agreements and significant downtime a check can be made by repeatedly sealing the vault and unsealing it with a different set of keys. This requires at least n/t (rounded up) seal/unseal operations, possibly with several people having to participate twice and causes significant downtime. In case of a rekey this changes an on-line operation into one that requires downtime.

Alternatively, in place of seal/unseal cycle a root token could be generated, but this is a much more dangerous operation, as the token would be, without any oversight, accessible to a single operator. This is against standard precautions when using a root token.

Explain any additional use-cases
Having a separate command that can be run independently has an additional benefit that the seal keys can be periodically checked to provide proof of possession.

Additional context
Side note: the verify option is very poorly documented. It's not mentioned at all at https://learn.hashicorp.com/vault/operations/ops-rekeying-and-rotating#rekeying-vault, barely mentioned without even explaining what it does on https://www.vaultproject.io/docs/commands/operator/rekey/ and only https://www.vaultproject.io/api-docs/system/rekey/#inlinecode-require_verification-3 provides some documentation on what the option does.

[ptrovatelli]

would be nice yes; you don't want to wait for the moment you can hardly reach to quorum to find out that some parties are not able to use their unseal keys because they've lost their pgp private key or something like that.

[pieter-lautus]

I am writing policies for our company's rekeying an unsealing procedures, and it is essential for business continuity that we can prove all of our unseal key holders actually hold a valid unseal key. Otherwise, if an key holder becomes incapacitated, we may discover we no longer have a quorum, and lost access to our company's Vault data.

I particularly like the idea of an independent operator verify command as suggested above, that can be configured with a greater threshold than the default unseal threshold. That way, we can perform regular "unseal drills" without incurring the actual downtime implied by sealing the vault.