Hi all, > 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 are human mistakes >so eliminating humans from CPS docs does address the problem in a meaningful >way.
I only partially agree. Automation is also (at least for now) written by humans and does and will contain errors. You shift the problem from humans creating documents to humans creating automation. Yes, once it's running properly, it will continue to so until something changes and it doesn't run or produces wrong output. Kind Regards Roman From: [email protected] <[email protected]> On Behalf Of Jeremy Rowley Sent: Donnerstag, 12. Juni 2025 20:30 To: Tobias S. Josefowitz <[email protected]> Cc: [email protected]; Wayne <[email protected]> Subject: Re: Results of 2025 Roundtable Discussion >> 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]<mailto:[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]<mailto:[email protected]>" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]<mailto:dev-security-policy%[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]<mailto:[email protected]>" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]<mailto:[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<https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAFK%3DoS_DZ-OsmRbctSLgpd2%3DDvQfqHJNouGZNzvOS2JcY_OG1A%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 visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/ZR0P278MB017063610B87D86014A25C1BFA77A%40ZR0P278MB0170.CHEP278.PROD.OUTLOOK.COM.
