Hi Tim, On Mon, Jul 15, 2024 at 09:22:22PM +0000, 'Tim Hollebeek' via [email protected] wrote: > If a publicly-trusted certificate is difficult to replace, for various > regulatory or technical reasons, the real reasons do not magically appear > when rotation is necessary. But a host of fake reasons are likely to arise > ("we can't rotate certificates faster because it costs money we don't want > to spend"). Furthermore, making progress on this problem would be greatly > assisted by better information about exactly which certificates can't be > replaced, the timescale on which they CAN be replaced, and why. > > The world would be better if we all knew, IN ADVANCE, which certificates are > automatically replaceable, and which aren't. This would also greatly > streamline operations when replacements are necessary, as it removes the > burden on making the determinations with a ticking clock, which is a > situation that doesn't lend itself to careful and unbiased evaluations.
If I'm understanding your proposal correctly, it basically requires organisations to identify, in advance, certificates which cannot be replaced in line with the WebPKI requirements. If so, while I agree with the motivations (to have more useful information), I have... questions: 1. What is the motivation for an organisation to take the time and effort to identify all problematic certificates? These organisations apparently don't have the available resources to fix the current problems, what will their reaction be to being asked to do even more work? 2. If an organisation does not proactively declare a problematic certificate as being problematic, what are the consequences at revocation time? I can't imagine that CAs will be willing to revoke those certificates even though the organisation has not declared them as problematic, for the same reasons that those CAs are not willing to currently revoke problematic certificates. 3. If an organisation is capable of proactively identifying problematic certificates, why issue a WebPKI certificate at all? On its face, a declaration that a certificate is incapable of being rotated in line with the requirements of the WebPKI is an admission that the customer is (or at the very least expects to be) in breach of their subscriber agreement. 4. For certificates that are problematic, why add an extension to a WebPKI certificate that says "this certificate is non-compliant", rather than just moving that usage to a private PKI. 5. Do you have any reason to believe that CAs and their customers will even be *willing* to disclose this sort of information? In every previous incident that comes to mind, the prevailing attitude from CAs has been to refuse to disclose customer information in any meaningful fashion. I can understand their reticence there on one level, as a protection against "customer poaching"[1], and I'd be hesitant for Mozilla to make it a requirement for CAs to disclose this from an anti-trust action perspective. > I realize this would be a major change to how we do things, but we've been > having this exact same conversation about certificate replacement for pretty > much the entire decade I've been involved at CABForum, and I think it's time > for radical change. If this isn't the right idea, it at least gives a sense > of the kind of change that is needed to make progress here, and I would love > to hear any other potential ideas for how we finally exit the traffic circle > and start moving forward again. My proposal is that root programs require CAs to accept revocation reqests from the root programs themselves for randomly-chosen certificates. At random intervals, a root program sends a (suitably authenticated) email to the CA's problem reporting address stating "this certificate should be considered compromised as of this moment, revoke in line with the BRs". Frequency and volume could be tuned to issuance volume, with upper and lower bounds as needed to ensure universal coverage without unduly burdening any particular CA with excessive administrivia. I base this proposal on two factors: 1. Regular testing of processes is important to be confident that those processes work. When I was running the Pwnedkeys Revokinator, I found plenty of problems with revocation practices at several CAs, resulting in multiple problem reports. I'd be more than willing to resurrect the Revokinator to once again analyse revocation processing compliance if I had confidence in support for it by root programs. 2. It would put *everyone* in the ecosystem on notice that revocation is something that needs to be planned for. At the moment, organisations can deploy their infrastructure on the basis that "it'll never happen to us, we don't lose our keys / suffer from bugs / whatever", and they don't consider other causes of revocation. While the probability of any particular certificate getting chosen would be very low, that *definite* non-zero probability is likely to get more attention than any number of out-of-the-ordinary incidents that organisations can dismiss with "well, *that* would never happen to us!" - Matt -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/7b7baffa-7fed-449d-ad0c-543abafed999%40mtasv.net.
