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/CADQzZqvAW706AbytEjY9ZfVG4Rinf2Vdn7cJMStE3_aXmPz2Zw%40mail.gmail.com.
