We don't need to block keys at the config level, that's what the blockedKeys database table is for. Having two separate mechanisms for blocking keys is confusing and may eventually lead to errors. The database method scales much better, so let's consolidate on that.
Note: to ensure that this is done correctly, do not deprecate the config field. Remove it wholly, causing boulder to error out if it is provided. That way we can ensure that nothing is accidentally still hoping for the config field to work, and no compliance errors arise when keys that should be blocked, aren't. This means we can't land a change for this until after we've confirmed that SRE has removed all usage of this config field.
Note: when we do this, remove //test/block-a-key as well.
We don't need to block keys at the config level, that's what the
blockedKeys
database table is for. Having two separate mechanisms for blocking keys is confusing and may eventually lead to errors. The database method scales much better, so let's consolidate on that.Note: to ensure that this is done correctly, do not deprecate the config field. Remove it wholly, causing boulder to error out if it is provided. That way we can ensure that nothing is accidentally still hoping for the config field to work, and no compliance errors arise when keys that should be blocked, aren't. This means we can't land a change for this until after we've confirmed that SRE has removed all usage of this config field.
Note: when we do this, remove //test/block-a-key as well.