>> It's not just 'a promise', it's a contractual agreement. I honestly find the resurgence of this CP/S discussion rather odd as I was under the impression it was re-discussed and agreed over a year ago with Entrust.
It was well-discussed that you right now a CA must revoke where your CPS does not match your operations. This has a race to the bottom effect on CPS docs where every CA is incentivized to copy and paste the BRs as their CPS. More disclosure = more risk = less transparency, which I think is a bad outcome. To date, all of these mis-issuances are primarily related to cert profiles and CAA records. I am awaiting the day where a CA must revoke all their certs because of a mistake in the choice of law provision or incorrect information in Section 8. Note that most contracts do not require you to terminate the services if wrong. You generally update the language or get a waiver from the party. The contract comparison doesn't really work because most breaches in contract do not result in turning off services - they result in the breaching party curing or obtaining a waiver. >> The decision to start talking about credits to subscribers is also rather narrow-minded on commercial CAs and their financial relationship with subscribers. That has no bearing on a CA's trust to relying parties, nor is it relevant to CAs that do not operate commercially such as Let's Encrypt. This was just an example. The primary question is whether you can carve out sections from revocation where the CA exceeds the BRs but wants to offer more information about how they operate. >> With regards to a disconnection between actual practices and what the contractual document states: that is a CA's problem to fix, and incentives must exist to that end. There's already an incentive to fix it as you'd still need to file a bug on any incorrect information. The question I'm asking is if there is a way to limit revocation to mistakes made in language that are not part of the BRs. >> What is the actual outcome that people want from a discussion on this front ultimately? We're approaching a bizarre choice to lower all expectations for any statement by a CA in legally binding documents to mean anything, on the off-chance that they are held accountable and must face minor repercussions. How is this creating a more trustworthy and transparent environment for the WebPKI to operate in? A way to encourage transparency from CAs without interfering with the role of the CPS. I'm looking at a way to get more transparency and accuracy around CA operations, which is not by having someone write more documentation. >> Frankly that the topic is also being brought up at CAB/F shows a lack of willingness by CAs to keep to their own agreements, and that reflects on the trust between parties. We can talk about automatically generating the certificate profile off of the actual configuration of issuance systems, but that seems to be a minor point of discussion and a bit irrelevant to the issue at-hand. I actually think that's the major point of discussion as I see the fundamental problem with CPS docs as human created. So machine readable profiles and operational docs are a good way to address some of the issues. Most of these CPS errors aer human mistakes so eliminating humans from CPS docs does address the problem in a meaningful way. On Thu, Jun 12, 2025 at 9:56 AM Tobias S. Josefowitz <[email protected]> wrote: > Hi Wayne, > > On Thu, 12 Jun 2025, Wayne wrote: > > > The decision to start talking about credits to subscribers is also rather > > narrow-minded on commercial CAs and their financial relationship with > > subscribers. That has no bearing on a CA's trust to relying parties, nor > is > > it relevant to CAs that do not operate commercially such as Let's > Encrypt. > > I am not sure I agree with that frame. While credits are a concept that > only applies to commercial CAs, there might be other concepts that achieve > the same for non-commercial CAs: A quantifiable incentive to adhere to the > stipulations in CP/CPS that go beyond the BRs. > > Even if for-free CAs do not find a concept that allows them to commit to a > similar, quantifiable incentive, it might still be a win for the > ecosystem if at least commercial CAs could make binding, incentivised > commitments this way. > > This would of course have to be testable and verifiable. In order to > achieve that, CAs making such commitments could also commit to disclosing > any violation of the "primary" commitment, including information allowing > to identify affected certificates. And in order for this to be an > effective incentive, the credit would also have to be credited if the > issue is reported by someone other than the subscriber. > > I imagine a second set of CRLs could be offered, in principle, stating > such affected certificates as revoked. This would allow for ecosystem > participants to determine relevant state with current tooling, and it > would even allow Relying Parties to use this second set of CRLs for their > revocation checking purposes - in theory - if that is what they seek. > > It is troubling that CAs do not have the confidence in their abilities to > adhere to the BRs, Root Store policies and even their own intentions to > the degree that they try to minimize "exposure" by minimizing additional > commitments in their CP/CPS, but ... that in itself is as valid as it is > regrettable. I sense we are stuck, and to move forward, we must think out > of the box a little bit. Especially if the alternative is publishing > errata, which is way less of an incentive not to screw up, if you ask me. > > 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 visit > https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/67b7a29e-7c24-5410-d5c4-28e04d72baa5%40opera.com > . > -- 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 visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAFK%3DoS_DZ-OsmRbctSLgpd2%3DDvQfqHJNouGZNzvOS2JcY_OG1A%40mail.gmail.com.
