A document that says "We do X, we do Y" but also says "YOLO" isn't much of a promise in my opinion, and CPSs are intended to be a promise.
Again, the problem here isn't that we have too much transparency, or that revoking certificates that break the few promises CAs make to relying parties is a problem. The problem is that these documents are treated as a compliance artifact, rather than a governing artifact and are therefore loosely created as "as built" specifications. In other words, they are something that is created to describe what the CA thinks they do, rather than what they hold themselves accountable to. To address the revocation problem, ironically, the CPSs need to be more explicit and used as governing documents as part of how operations and engineering are done. They need to be written with accountability and testability in mind to be useful in that function, not reduced to platitudes. Ryan On Thu, Jun 12, 2025 at 6:05 AM Jeremy Rowley <[email protected]> wrote: > Would that be allowed and also avoid revocation of your missed it? Could > you put something in the CPS that said “We endeavor perform everything as > stated in this CPS but there > May be slight deviations. If there’s any deviation from the CPS, we don’t > revoke but offer a credit of X. We always revoke for noncompliance with the > BRs. ” > > If this would actually allow you to disclose more info without revoking if > something goes sideways with that additional disclosure, then it’s a good > solution and worth trying. > > On Thu, Jun 12, 2025 at 8:49 AM Tobias S. Josefowitz <[email protected]> > wrote: > >> Hi Jeremy, >> >> On Thu, 5 Jun 2025, Jeremy Rowley wrote: >> >> > Although lots of CAs put additional controls on their CA above and >> > beyond the BRs, I would not put those into a CP. Instead, I would offer >> > them as an SLA to the agreement or similar practice. If you violate one >> > of those, the customer gets a credit instead of a revoked cert. The CA >> > still shows that they are doing more than the minimum but they don't >> > risk revocation if a control fails. >> >> Could such additional controls not be put into CP/CPS as a conditional >> commitment on either fulfilling them or offering the subscriber credit? >> Such that it would then only be a CP or CPS violation if the control was >> violated AND the subscriber did not get credited? This would offer >> transparency to Relying Parties, as well as a commitment to either uphold >> the controls backed by a mechanism incentivising the CA to follow >> through? >> I imagine that might be useful for trust decisions by a Relying Party... >> >> 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/CAFK%3DoS-TdnuLQr_3DsUgZqdgz9Pg%2BiLCscDdSJkv0n7W1%3DQL1Q%40mail.gmail.com > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAFK%3DoS-TdnuLQr_3DsUgZqdgz9Pg%2BiLCscDdSJkv0n7W1%3DQL1Q%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/CALVZKwbauP89EXpiognzZG-z3nGqC3DY4Nj5-SSMp7J4QQG9SA%40mail.gmail.com.
