Key Commitment Not Updated in Browsers After Key Rotation

[hardikbkk]

Hi Team,

We rotated our keys on September 24, 2024, at 6:30 AM UTC. During this rotation, we changed the keys and incremented the commitment ID by 1, while keeping other details (such as expiry and key_id), same. However, it appears that the key commitment has not been updated in the browsers. <key commitment link: https://www.amazon.com/tt/k>
Can you please advise what else is required for key commitment changes to be picked?

[hardikbkk]

@dvorak42

[dvorak42]

Unfortunately it appears there was a bug on our side with how we were tracking the last time we saw a key commitment update from the server (for ignoring key commitment updates more frequently than allowed). It should now have picked up the key updates, it can take up to 4 hours for a Chrome client to automatically update the component, though you can force an update by going to "chrome://components/" and hitting "Check for Updates" under "Trust Token Key Commitments".

We're working on some more automation and testing to try to prevent other issues like that from cropping up.

[hardikbkk]

Thanks for the fixing it.
Wanted to know, at max how much time it take to rollout new key to all chrome clients? asking because we are still seeing 60% of request from older keys (it is decreasing gradually).

[dvorak42]

Are these issuance requests or token redemption requests?

For issuance, keys should be rolled out at the speed of the component update being distributed (it actually looks like its now a baseline of 5 hours between component update checks, rather than 4 hours), Most clients should have new keys after 5 hours of being up (or ~6 minutes from Chrome startup). I'd expect more like 90% of clients to be on the new keys after 24 hours, with the remaining rolling out over the week as less consistently connected clients update their keys.

For cached redemptions (RRs), we don't immediately discard RRs on a component update, and instead do the update when we next attempt to use the keys, so you may see requests with older keys there, though they should update once you're issuing new issuances/redemptions.

You don't have a breakdown on the Chrome versions you're seeing, do you? I wonder if there's some other issue with older Chrome versions getting the updates less frequently for some reason.

One API change we've been considering to help with the key mismatch is including information about the keyset that Chrome currently knows about as part of issuance/redemption, so the server can issue and redeem to the appropriate keys. Would that be useful for your deployment strategy or are you already doing trial decryption on the redemption side with both the old and new keys?