Quoting Gerv from the latest StartCom thread [1]: "* The key for their new root certificate was also used in a couple of intermediates (one revoked as it was done incorrectly - again, lack of testing!). While this is probably not a policy violation, it's not good practice."
Everyone including StartCom itself acknowledges that the one "done incorrectly", the revoked one, shouldn't have happened. This thread is not about that. I want to understand the meaning and reasoning for the rest of the bullet point as it makes no sense to me. I asked this before in the StartCom/Certinomis thread [2], where Kathleen said the same as Gerv, but it got no response, so I'm trying again. I can think of 3 ways to support old and new roots in parallel: 1. In the other thread I mentioned that major CAs like Amazon [3], Comodo [4] and GlobalSign [5] also seem to use the key for a root cert in an "intermediate". This is used to create the following trust paths: modern client: new root (in store) --- issuing intermediate A0 --- leaf legacy client: old root (in store) --- new root! (same key/name, but different cert; "intermediate") --- issuing intermediate A0 --- leaf 2. The alternative solution seems to be to "reuse" the key of the issuing intermediate instead, as done by e.g. Entrust [6] or Let's Encrypt/IdenTrust [7]. Paths: modern: new root --- issuing intermediate A1 (eg signed by ISRG Root) --- leaf legacy: old root --- issuing intermediate A2 (same key/name as A1, different cert, eg signed by IdenTrust) --- leaf 3. Yet another solution would be to have no key/name sharing @ CA level, and instead sign a leaf with multiple keys during the issuing process to create multiple unrelated paths. That would result in having more than one leaf cert though, so it is not a viable solution in general. modern: new root --- issuing intermediate N --- leaf L1 legacy: old root --- issuing intermediate O --- leaf L2 (different cert, but possibly same key) Looks like StartCom chose 1. [8] instead of 2. This was explicitly permitted by Mozilla in [9]. So why are they now criticized for it? Am I missing something, did I get it wrong above? In general: Is 1. really "not good practice" to switch roots, do Mozilla or others prefer 2.?* * I sure hope not. Option 1 implicitly makes server admins provide either only the new path, or both old and new paths, never just the old one. Option 2 allows "only old" as well. Since trust stores keep old roots for compat, "only old" works when admins test it, so they can use that and forget "new". Hence you can't easily remove legacy roots from the trust store because compat; chicken/egg. (unless you get the right=new intermediates into the trust store/interm cache/validation path somehow; that's ugly but sometimes possible e.g. with NSS you can have neutral trust entries and iiuc AIA chasing could also do this?). _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
