On Fri, 9 Aug 2024, [email protected] wrote:
The point of the Web PKI is to convey a public key approved by some party authorized represent some name to a client. The paperwork for CAs is to hopefully avoid them accepting a binding from anybody but the person who controls a name. If the person who controls a name is happy with a certain binding existing why is it anybody else's business what that binding is?
One of the reasons why this is problematic is because approaching it like this gives way to the potential for misaligned incentives. For example, a site may chose to stick with a compromised certificate because they might prioritize availability over security. Users would not in all cases prioritize in the same way. For example, a user might prefer (if they had full insight into the situation) to shop at a competing e-commerce site over using one with a compromised certificate.
In today's web, the majority of HTTPS requests are made to sites that the users do not even actively chose to interact with, but that are instead included by websites they may have actively chosen to interact with, for example ad networks, analytics, fonts, javascript frameworks, payment processors... to just name a few. A lot of users would be affected if such sites were incentivized (even more) to prioritize availability over integrity.
Another option would be to give these most likely large organisations with hard to replace certs a sub ca with critical name constraints, the BRs applicability should be re-scoped to stop at the sub-ca certificate. If the organisations chose to operate this sub-ca poorly then that is their problem as they cannot only affect the security of connections to their names.
For similar reasons this is equally problematic, in particular the "that is their problem" part. It is generally not only "their" problem, and that needs to be reflected in the WebPKI regulatory frameworks etc.
Tobi -- 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/a7f43008-f6c4-d3be-5d7c-53f37c1ecbd9%40opera.com.
