Rotating Root Keys section solution to trust intermediates instead of roots is unclear

[nharper]

Clients can withdraw trust in these older root keys by instead selecting their shorter lived intermediate certificates as trust anchors. These intermediates are generated much more frequently and are already widely distributed to browsers via the CCADB. This solution only works for clients that can stay up to date and if they go an extended period without updates, the browser can automatically fallback to trusting the corresponding root certificates. This is similar to existing certificate transparency mechanisms which self-disable after around 8 weeks. Clients that choose to anchor trust in the intermediates and clients that choose to anchor trust in the roots can both consume the same certificate chain without issues.

I can’t figure out what problem this is attempting to solve. The best I can figure out is that this is an alternative to CAs rotating root keys, i.e. it’s a way to allow CAs to have root keys live approximately forever, and the risk associated with not rotating keys is mitigated by having clients (when they’re up to date) trust only the intermediates issued by the root instead of trusting the root itself. This risk is also mitigated by checking CT logs for (intermediate) certs issued by the root that aren’t disclosed in CCADB. If that’s what this paragraph is proposing, it doesn’t help with the problem of what to do when root keys are rotated, which is the problem that trust anchor negotiation mechanisms help with. (See also https://github.com/dennisjackson/trust-negotiation-comments/issues/5.)

[dennisjackson]

I think this is addressed in #5 - but feel free to re-open if not.