”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 <mike.sha...@gmail.com> wrote: > On Wed, Jun 26, 2024 at 2:40 PM Zacharias Björngren < > zacharias.bjorng...@gmail.com> 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 "dev-security-policy@mozilla.org" group. To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-policy+unsubscr...@mozilla.org. 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.
