skip to content

A federation signing key was held for a year; how do you re-establish trust with relying parties you cannot compel?

level: principalimportance: nice to knowfreq 24%

answer

  1. who trusts you, and who can refuse
  2. overlap keeps the old key working
  3. the acceptor list is never complete
  4. no list of forged identities exists
  5. rehearse rotation before you need it

basics

~20 s

Replace the key and get every relying party onto the new one. You cannot compel third parties, enumerate them reliably, or say which identities were forged, so this is a negotiated programme with named owners and deadlines, not a change window.

solid answer

~50 s

Three hard parts, none of them cryptographic. First, inventory: you must find every party that trusts this issuer, including ones that fetch trust material automatically, ones where a certificate was uploaded by hand years ago, and integrations whose owning team no longer exists. Second, leverage: parties you administer move when told, parties bound by contract move when the contract says, and the rest move on their own schedule. That forces an overlap period in which both keys are accepted, and every day of overlap is a day the old key still mints identity, so the cutover length is a commercial negotiation, not a technical parameter. Third, the unanswerable question: the issuer never issued the forged identities, so nothing at the issuer names them. You can state the window and the reach honestly; you cannot hand anyone a list of impersonated accounts, and promising one is the failure mode.

go deeper

for a junior

Understand the shape rather than the programme: replacing a signing key means every party that trusts it must take new material, and some of those parties belong to other companies.

for a middle

Explain why an overlap period is needed, what it costs while it runs, and why the acceptor list is usually incomplete in a real estate.

for a senior

Show you would sequence this by leverage, state exposure as a window rather than a list, and design the cutover so a slow relying party degrades rather than blocks the whole programme.

for a principal

Own the trade explicitly: overlap length against broken relationships, the wording of the claim you make to customers and regulators, and the standing investment in rehearsed rotation and a live acceptor inventory that makes the next one routine.

## Why this is a principal-level problem Everything technical about replacing a signing key is well understood. What makes this hard is that the parties who must act are not yours. The issuer's owner has authority over the key and no authority over the acceptors, and the acceptors are the ones whose action determines whether the old key is still good. That is an organisational problem wearing a cryptographic hat. ## Part one: you do not know who trusts you Start with the acceptor set, because everything else is scheduling against it. It typically has three strata: - **Automatic consumers** that periodically fetch published trust material. These move on their own once you publish, and they are the easy majority. - **Manual consumers** where somebody once pasted a certificate into a configuration screen. These need a human on the other side, in their change window, with a ticket you cannot raise. - **Unknown consumers**: integrations built years ago, subsidiaries, acquired businesses, a customer who federated to you as part of a deal nobody remembers. These surface only when they break. The honest deliverable here is a list plus a stated confidence, not a claim of completeness. If your programme's plan assumes the list is complete, the third stratum will find you at cutover. ## Part two: leverage decides your schedule Sort the acceptors by what moves them. Internal systems move because you own them. Customers and partners under contract move because a clause obliges them, and you should know before the meeting whether such a clause exists. Everybody else moves when it suits them, and a large customer may simply refuse a date that collides with their own freeze. The mechanism that keeps them working during this is publishing both keys, and it is a genuine cost rather than a formality: while the old key is still published and accepted, whoever holds it keeps minting identity. So the overlap window is the exact quantity being traded. Shorten it and you break slow relying parties, possibly including revenue-bearing ones. Lengthen it and you extend the exposure you are trying to end. Making that call, with a number and a named owner for the parties who miss it, is the decision the question is actually asking about. ## Part three: the claim you cannot make Because forged identity involves no issuance, there is nothing at the issuer naming the identities that were forged. A year of exposure therefore cannot be converted into a list of affected accounts. What you can state defensibly is the window during which forgery was possible, the reach (anything trusting this issuer would have accepted it), and what has changed since. This matters commercially. Customers and regulators ask for a list, and the pressure to produce a plausible one is real. A list assembled from partial sources will be read as complete and will be wrong, and the correction is far more expensive than the original honest bound. Decide the wording of that bound once, centrally, and make every conversation use it. ## Part four: what you change so that the next one is cheaper The design outcome, not the response, is what a lead is judged on afterwards: - **Rehearse replacement.** A trust anchor that has never been rotated on a calm Tuesday cannot be rotated safely on a bad one. Regular, boring rotation converts a crisis into a procedure and shrinks the overlap you will need. - **Publish trust material in a form consumers fetch automatically**, and make automatic consumption a condition of new integrations, so the manual stratum stops growing. - **Maintain the acceptor inventory as a live thing** with an owner, because the inventory is what bounds every future statement you make about reach. - **Constrain who can invoke signing**, so that possession of the appliance holding the key is not the same as the ability to issue identity unobserved. - **Prefer credentials a relying party must resolve with the issuer** at the relationships you could least afford to lose, accepting the coupling that comes with it. ## The trap to name out loud The seductive framing is *rotate the key and we are done*. Rotation is the easy hour. The programme is the six weeks of chasing parties who do not report to you, with an exposure clock running the whole time, and a statement to customers you must be able to defend without over-claiming.

  • Why does publishing old and new keys together weaken the fix?
    Because during the overlap the old key is still accepted, so whoever holds it keeps minting identity. The overlap exists only to avoid breaking relying parties that take up new trust material slowly or by hand. Its length is therefore a trade between broken integrations and continued exposure, which makes it a commercial decision with a technical consequence rather than a configuration detail.
  • What can you honestly tell a customer whose users may have been impersonated?
    The window during which forgery was possible, the reach, and what has changed. You cannot give them a list of impersonated accounts, because the issuer never issued those identities and holds nothing naming them. Promising a definitive list is the failure mode; stating the bound plainly, in wording agreed once and used everywhere, is the defensible position.
  • A major customer refuses to take the new key inside your cutover window. What now?
    Escalate it as a business decision with the exposure stated numerically, not as an engineering blocker. The realistic options are extending the overlap for that relationship alone, moving them to a separate trust with its own key so the rest can cut over, or accepting a break on the agreed date. Whichever is chosen, someone senior has to own it in writing.

saying these in an interview costs you the question

  • Treats key rotation as a single technical change window
  • Assumes every relying party can be forced onto a new key
  • Promises customers a definitive list of impersonated accounts
  • Forgets the old key stays acceptable during the overlap
  • Never asks who consumes the issuer's trust material

context