I think it would be good to collect and analyze use-case environments from subscribers who have requested delayed revocation, if anyone has bandwidth. Thanks, Ben
On Wed, Jun 26, 2024 at 2:15 PM Zacharias Björngren < [email protected]> wrote: > ”Non-production services aren’t critical, and should just be trivially > revoked until they can be replaced. (Or the non-production services should > be configured to ignore revocations in some cases, I guess.)” > > While I see your point I also think that non-production services could > still be part of the greater system, where the purpose of those > non-production environments is enable testing and verification of changes > with much lower stakes. But then again I’m confused about how replacing a > certificate could involve the amount of effort and bureaucracy that is > being claimed in all these delayed revocation incidents. > > > On Wed, 26 Jun 2024 at 21:00, Mike Shaver <[email protected]> wrote: > >> On Wed, Jun 26, 2024 at 2:40 PM Zacharias Björngren < >> [email protected]> wrote: >> >>> I’ve been thinking a lot about the first question, ever since I noticed >>> how many of the certificates I sampled in lists of certificates for delayed >>> revocation incidents included clear markers of not being a production >>> environment. It was: dev, test, preprod, uat. It felt like a majority of >>> them did, which makes sense if using webPKI for such environments is >>> commonplace. I would have thought that more organizations used a private CA >>> for these scenarios, but apparently not. >>> >> >> There is no open source software package that rolls up all the CA >> activity and the policy management for root registration on browsers and >> servers, etc. I think that would spur a lot more use of private CAs. >> >> If there is a security issue then delayed revocation of certificates >>> protecting critical infrastructure could risk greater harm than just >>> revoking. To incentivize prompt action for the production environments >>> delaying revocation for non-production environments could give >>> organizations a chance to focus without having to worry about non-critical >>> hosts. >>> >>> In case of mississuance it could be better to allow an organization to >>> delay revocation of their production environments so that they can verify >>> that their reissued certificates work using their test environments. >>> >> >> Non-production services aren’t critical, and should just be trivially >> revoked until they can be replaced. (Or the non-production services should >> be configured to ignore revocations in some cases, I guess.) >> >> Reasoning about attention splitting and bandwidth requires more knowledge >> of how the organization is structured and their capabilities than I am >> likely to have. >> >> I also reacted to how many of the certificates were for domains that did >>> not appear to have public DNS entries. And I’ve noticed some reluctance to >>> reveal more detailed information about why a system is critical with >>> references to security. I think that if the claim is made that: Yes this >>> host is part of critical infrastructure, no it is not publicly available, >>> and no >>> we won't tell you what it does. Then the only proper answer is to hand >>> them instructions to set up their own private CA. But that is a separate >>> issue I guess. >>> >> >> I think that “get off the web PKI” is indeed the right remediation for a >> system that cannot tolerate web PKI revocation policies, and unlike >> “educate customers” has a somewhat observable outcome (revocation of the >> web PKI certs in question). In a nice alignment of interests, some CAs also >> offer products and services related to building and operating a private PKI. >> >> (“Pinning” should only be allowed to delay revocation once for a given >> organization. Replace it with validation of a key the operator controls. A >> CA that knowingly issues a cert that will be pinned in a too-big-to-break >> context is bumping up against some good-faith issues IMO.) >> >> Mike >> >> -- > 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/CAKDW-UeAT-PhE-MMKyS7Xa%2BryoCrYD49rKoX82hEhD7bGXMHDQ%40mail.gmail.com > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAKDW-UeAT-PhE-MMKyS7Xa%2BryoCrYD49rKoX82hEhD7bGXMHDQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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/CA%2B1gtaa2YjiWNww8YNu8YGjgo8-%2ByBvU4dh3_1d52fqurVLkdw%40mail.gmail.com.
