It is (probably) okay to decrypt a message with a revoked, expired or weak key

[nwalfield]

secret_key_from_cert is used by decrypt to decrypt a message:

securedrop/redwood/src/keys.rs

Lines 40 to 48 in 8d00ba5

	/// Get the secret encryption key, which is the first and only subkey, from the cert.
	pub(crate) fn secret_key_from_cert<'a>(
	policy: &'a dyn Policy,
	cert: &'a Cert,
	) -> Result<Key<SecretParts, UnspecifiedRole>> {
	// Pull the encryption keys that are compatible with by the standard policy
	// (e.g. not SHA-1) supported by Sequoia, and not revoked.
	// These filter options should be kept in sync with `Helper::decrypt()`.
	let keys: Vec<_> = filter_keys!(cert.keys().secret(), policy).collect();

But, there is no reason to not decrypt a message if it key is expired, revoked, the policy says the algorithms are no longer strong enough. Is there?

[legoktm]

In the current context of SecureDrop it's a bit theoretical. Source keypairs are fully created and managed by SecureDrop, so there should never be a scenario with an expired or revoked key.

AFAIK SecureDrop has always generated keys that are compliant with the current standard policy, but I agree with you that it doesn't make sense to prevent decryption of messages because of that.