Hello Ryan, Thanks for your detailed response. Just to be sure that we are in the same page. My question was about reissuing a new CA using the same key pair, but this implies also the revocation of the previous version of the certificate.
You elaborate the need to revoke, but this would be still done anyway. Thanks, Pedro El jueves, 2 de julio de 2020, 22:11:52 (UTC+2), Ryan Sleevi escribió: > On Thu, Jul 2, 2020 at 2:34 PM Pedro Fuentes via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > Hello. > > Sorry if this question is incorrect, but I’d like to know if it would > > acceptable that, for CAs that are owned and operated by the same entity > > that the Root, the CA certificate is reissued with the same key pair > > without the offending EKU, instead of doing a full issuance with new keys. > > I consider this particular case as less risky than externally operated > > CAs, so I wonder if this could make possible an smoother solution. > > Your comments and guidance are appreciated. > > Thanks, > > Pedro > > > > This is definitely a hard question, but I don't see how we can easily > resolve that. That's why the comments about Key Destruction were made. > > So, first, let me say it definitely mitigates *some* of the security > concerns, particularly the most major one: a third-party being able to > arbitrarily "unrevoke" a certificate, particularly "their" certificate. In > the cases of 3P Sub-CAs, this is just so fundamentally terrifying. Even if > the Sub-CA "hasn't" abused such a capability, the mere knowledge that they > could gives them greater flexibility to "live dangerously" - or to make > them a ripe target for compromise. > > Now assuming the keys are all part of the same (audited) CA infrastructure, > what does the risk perspective there look like? In effect, for every > Issuing CA that has issued one of these, Browsers/Relying Parties have no > assurance that any revocations are "correct". This is important, because > when a CA revokes a Sub-CA, even their own, we often stop worrying about > audits, for example, or stop looking for misissued certificates, because > "of course" these certificates can't be used for that purpose. The mere > existence of these certificates undermines that whole design: we have to > treat every revoked Sub-CA as if it was unrevoked, /especially/ if that > Sub-CA was the one that had the EKU. > > Now, it might be tempting to say "Well, can't we audit the key usage to > make sure it never signs a delegated OCSP response"? But that shifts the > burden and the risk now onto the client software, for what was actually a > CA mistake. A new form of audit would have to be designed to account for > that, and browsers would have to think *very* carefully about what controls > were suitable, whether the auditor was qualified to examine those controls > and had the necessary knowledge. In short, it requires Browsers/the client > to work through every possible thing that could go wrong with this key > existing, and then think about how to defend against it. While the CA might > see this as "saving" a costly revocation, it doesn't really "save" anything > - it just shifts all the cost onto browsers. > > It might be tempting to ask how many had the digitalSignature KU, and can > we check the KU on OCSP responses to make sure it matches? In theory, > clients wouldn't accept it, so they wouldn't be unrevocable and able to > cause shenanigans, and we're saved! But again, this is a cost transfer: > every client and relying party now needs to be updated to enforce this, and > work out the compatibility issues, and test and engineer. And even then, it > might be months or years for users to be protected, when the BRs are > supposed to provide protection "within 7 days". Even "clever" alternatives, > like "Don't allow a delegated responder to provide a response for itself" > don't fully address the issue, because it can still provide responses for > others, and that would further require mutating the revocation checking > process described in RFC 5280 to "skip" OCSP (or fall back) to CRLs. All of > this is more complexity, more testing, and contributes to the body of "dark > knowledge" needed for a secure implementation, which makes it harder to > write new browsers / new libraries to verify certificates. > > This is the risk analysis we expect CAs to work through, and think about. > What is the cost of this decision on others? Often, CAs focus > (understandably) on the cost to those they've issued certificates to, but > ignore the externalized ecosystem that they're simply shifting those costs > to. The BRs try to force the CA to account for this up front, because they > *know* that if *anything* goes wrong, they have 7 days to revoke, but then > they don't design their PKIs to be resilient for that. > > You can imagine a CA that was rotating issuing intermediates every year > would be in a better position, for example, if this was a "previous" > mistake, since fixed. The impact/blast radius of revoking an intermediate > is a linear decay tied to how many unexpired certificates from that > intermediate there are, which is precisely why you should rotate often. > It's a point I've made often, especially with respect to certificate > lifetimes, but it still doesn't seem to have been taken to heart yet by > many. I'm encouraged GlobalSign's new infrastructure appears to be doing > so, and although it was also affected by this issue, it's hopefully > "easier" for them to clean up versus others. > > But this is what disaster recovery plans are for. The "compromise" of a > delegated signing CA is, as noted in RFC 6960, in many ways *as bad as* > compromise of the CA key. CAs have to get better at planning for things > blowing up, and I hope every incident report looks at exactly those best > practices: minimizing the pain of revoking a cert within 7d. > > For CAs with non-TLS certs, this is going to be especially painful to > revoke, but it's still necessary. This underscores the "Don't use the TLS > root to issue non-TLS certs". _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
