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.
