Hi Matt - to continue the conversation (and note that I am not Tim and that these are my own thoughts, not necessarily the position of Digicert):
> 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? I think you'd find organizations willing to admit this information upfront if it was the only way to delay revocation past the required timeframe. This also is a question that can be asked to capture which companies are using automation and expand on reasons some companies are not using automation. One note is that I disagree that resources are a major issue. They always are, but I believe the real issue are policies that prevent quick replacement and less efficient practices. Even people with ACME sometimes have weird approval workflows before the automation can do its job. This plan also doesn't account for when random stuff that goes wrong. For example, you have a major breakage during cert replacement. I don't see how people can account for that upfront. Will it prevent all delays? Likely no, however this idea gets user information upfront to the community instead of trying to provide that while operating in crisis mode. > 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. I think it helps emphasis that prompt revocation is required. Ie - "You said you could revoke in 5 days an now can't - what changed?" Although the revocation language already appears in agreements as boiler-plate, it doesn't hurt to call it out. The other reason I like Tim's idea is because its pretty easy to implement and see what we get back. Do subscribers care so much about delayed revocation that they are willing to state they can't do it? I think you'd want the Mozilla policy to be that delayed revocations are not accepted unless this is declared up front. > 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. The providers are part of the WebPKI as it includes online banking or healthcare, which are accessed via browser. The fact a subscriber would be in breach of their agreement with the CA is interesting. That would need some workshopping. > 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. A lot of these aren't private-facing. They use a browser for access to the site or service. > 5. Do you have any reason to believe that CAs and their customers will evenbe *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 think disclosure is cost of not being able to revoke in 5 days. I definitely agree with you that disclosing this information would be hard to make happen, but the cost to set up the experiment is pretty low. Anyway - I wanted to respond so the thread didn't get lost as I liked your comments and Tim's proposal. -----Original Message----- From: [email protected] <[email protected]> On Behalf Of Matt Palmer Sent: Monday, July 15, 2024 8:10 PM To: [email protected] Subject: Re: Feasibility of a binding commitment to revoke before issuance 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://url.avanan.click/v2/___https://groups.google.com/a/mozilla.org/d/msg id/dev-security-policy/7b7baffa-7fed-449d-ad0c-543abafed999*40mtasv.net___.Y XAzOmRpZ2ljZXJ0OmE6bzpmY2RlMDNiOTIwZWFiMDQ5NTRlYTM5OTc2YTJmMzJlZjo2OjMzN2M6Y mVlMWRiZjg2ZWRmYWQyNTg1ZDA2OTQ4YzU4ODIzN2NhZGE5OTJlMTE1NTQzODc0ZGQ2MDkyYWIwY jg1MjFkYjpwOlQ6Tg. -- 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/PH7PR14MB7394F39F6C38C535C7360AC58EAA2%40PH7PR14MB7394.namprd14.prod.outlook.com.
smime.p7s
Description: S/MIME cryptographic signature
