kafka redemption should permit redemption with non-current but still valid keys

[tackley]

Currently the logic in signed_token_redeem_handler only checks for redemption against the most recent key for each issuer:

challenge-bypass-server/kafka/signed_token_redeem_handler.go

Lines 158 to 162 in 1a4af4e

	// get latest signing key from issuer
	var signingKey *crypto.SigningKey
	if len(issuer.Keys) > 0 {
	signingKey = issuer.Keys[len(issuer.Keys)-1].SigningKey
	}

This means that when we rotate keys every single previously issued token immediately becomes invalid and non-redeemable, making rotation impractical. (Or forcing us to treat non-redeemable keys as valid, as we had to do this time.)

Instead, it should attempt token redemption if a key exists with the supplied public key and has a null or future end_at timestamp. This will allows a cross-over period after rotation.

[Sneagan]

Here's what I think needs to change to enable this:

1. Update the redemption flow to fetch the issuer by public_key. This field is already present in the Avro schema as well as the latest keys.
   a. @husobee @clD11 It ought to be the case that a public key lookup would give us the same result as the current query in cases where the public key is provided, so the only impact would be for requests that do not include the public_key field in their request. In that case, we should fall back to fetching the latest valid key by name and cohort. Is this safe to do without negatively impacting your use case or do we need to branch the logic further here?
2. Update the v3_issuer_keys table with start_at and end_at for existing keys in relevant databases.
3. Insert the public key into historical key rows that need to be considered valid (if any).

It's also worth noting that we will need an additional issue to represent the work of automating key rotation. This issue is narrowly focused on ensuring desired behavior when keys are manually rotated.

[husobee]

1a - Makes sense to me, if we have a public key use that for the lookup. Do we need to consider an EOL field for keys (end_at possibly) for redemptions to be allowed?
3 - I believe I made a tool @Sneagan for us to generate the existing public keys from an export of secret keys, do you have that still?

[Sneagan]

1a. Yes, I think end_at is what we should use. If we overlap the start_at of the new key with the end_at of the old key we should get the desired effect.
3. Yes, that's exactly how we'll do it if needed. I updated it with the ristretto changes a few weeks back so it is still functional. I went ahead and made a PR for that in #493.

[johnhalbert]

@Sneagan https://github.com/brave-intl/challenge-bypass-server/blob/490-allow-redemption-with-non-current-valid-keys/kafka/signed_token_redeem_handler.go#L154-L212

Does this look right to you?