Rotating Root Keys section in usecases doc confuses problems with solutions

[nharper]

The first use case described in the proposals is making root key rotation in the WebPKI easier. Currently, the WebPKI has several ~20-year-old root keys which are used to sign shorter lived intermediate certificates.

The proposals describe this as a security risk and propose a new solution.

The solution to the risk of long-lived keys is to rotate keys more frequently. However, the solution of rotating keys more frequently introduces a new problem of when to rotate keys without introducing breakage. Trust anchor negotiation mechanisms solve that problem.

Much of the "Rotating Root Keys" section goes off on a tangent about intermediates being disclosed to CCADB and the relative value of an attacker gaining control of a root key vs an intermediate key. This is only an argument for how long root keys should be trusted relative to intermediate keys (I don’t see any disagreement that intermediate keys should be shorter lived than root keys), but the problem here is what to do when root keys are rotated. The lifetime of intermediate keys is irrelevant when it comes to how subscribers and clients handle root key rotation.

[dennisjackson]

I understand your confusion. You're putting forward the case that the problem we need to solve is making root key rotation easier. I don't believe that's a real problem.

The text describes why I feel that is not a real problem: a) The only reason we rotate keys is for the benefit of the security of the clients who trust those keys. In the case of root certificates, this is relatively unimportant. b) we have existing key rotation mechanisms which work perfectly fine.

I've tried to make this clearer in the draft. Perhaps you can describe why you think the existing key rotation mechanisms are painful?

[nharper]

I see your update is to say that rotating root keys is a solution to a problem ("clients are trusting keys which are too old and so bad for security"), and you use the rest of the section to argue how this problem could be solved in ways that don't require rotating root keys.

Key rotation of root keys in the Web PKI is something that exists and will continue to exist. Claiming that root keys don't need to be rotated goes against security best practices, existing Mozilla root program policy (section 7.4), and Chrome root program vision.

Argument (a) for why it's not a real problem is based on intermediate disclosure in CCADB and a claim that clients could trust intermediates instead of roots (except for old clients). This is a design proposal for an alternative way to handle the "keys are too old" problem that key rotation solves. It does not address the reality that root keys are and will continue to be rotated.

Argument (b) is an argument in support of key rotation being a problem with the Web PKI that needs to be solved. There is some pain associated with key rotation as described in the explainer, and trust anchor negotiation helps alleviate that pain. Cross-signs is one way to solve it; trust anchor negotiation is another way to solve it.

[dennisjackson]

Given Cross-Signing already works with essentially every device that consumes TLS, you need to clearly identify some key rotation pain that Trust Expressions / Trust Anchors addresses that Cross-Signing does not. Saying they are equivalent is a very bad argument for investing time and energy in new designs. If you come up with something, feel free to open a new issue.