Intermediate Key Revocation

As part of the core design, we control intermediate keys through frequent rotation. However, if we found that an active intermediate key leaked, we don't currently have a way to revoke it before its expiration. While I'm generally skeptical of traditional revocation designs -- they tend to be brittle in performance/availability (fail secure) or integrity (fail insecure) -- I think we still need to address this scenario, even if not as part of MVP.

One option with minimal impact on the design is implementing a high-water mark for intermediate public keys tracked on each client against each root. We currently only support a single root of trust, so we'd initially only need one high-water mark. This scheme would work by rejecting intermediate public keys with earlier expirations once a client has seen a valid intermediate with a later expiration. Effectively, each intermediate would revoke the previous. This would create some weirdness in mirroring scenarios, as builds with old (but technically unexpired key) signatures become unusable until refreshed, so I'm not sure this is the right call, either.

Yet another option is to rotate so frequently that we're comfortable relying exclusively on rotation for revocation. This approach would also affect the viability of mirrors.