I guess actionable steps that I see that would improve the CPS situation: 1) Require the repo to be in github instead of a CPS document 2) Require the profile and CAA information to be extracted directly from the CA's systems 3) Require the CA to disclose more about the validation methods used (be interesting to see a CA list the percent they use each validation method).
On 3, a ledger that logs each domain's validation method would be a better solution if we can get there. On Fri, Jun 13, 2025 at 8:18 AM Jeremy Rowley <[email protected]> wrote: > For clarity - I am not representing a CA and do not have the authority to > represent any CA. My comments are my own. > > I think the credits are a red herring and just an example of the question. > Can a CA avoid revocation for something wrong in their CPS by adding > qualifying language? My thought is no. If this is a contract, then you > would certainly be able to do so, which means the contract analogy doesn't > really work as "reasonable efforts" is a pretty common phrase as is a > limitation on remedies. I don't think we should pretend the CPS is a > contract as the penalty for breach is set and doesn't appear movable. The > CPS is a requirement document with a stated requirement if you fail to meet > those expectations - revocation of certificates. If that's not true, then > the example scenario of offering credits instead of revocation would be > totally legit. > > If it is a requirements doc, I think it would be interesting to create a > CPS that just has the useful information and cuts out everything that > doesn't make a difference to relying parties (such as section 8 and 9). > > > On Fri, Jun 13, 2025 at 6:35 AM Mike Shaver <[email protected]> wrote: > >> On Fri, Jun 13, 2025 at 5:58 AM Tobias S. Josefowitz <[email protected]> >> wrote: >> >>> And in that scenario, I fail to see how transparently communicated >>> commitments alongside the incentive structure of the CA to follow them >>> would create a dynamic subject to your concern. >>> >>> Is the concern that "rich" CAs would voluntarily commit to additional >>> limitations, only to then violate them as some part of a "weird flex"? >>> If >>> not that, what is it? >> >> >> Right now there is nothing punitive about a CA’s responsibilities in the >> face of CPS-related misissuance: the things required of them are strictly >> remedial, being simply to correct the error they imposed on the WebPKI’s >> collection of valid certs. They don’t even require revocation, if the CA >> has chosen to structurally mitigate the risk of misissuance by issuing >> Short-Lived certificates. There is nothing inflicting harm as an attempt to >> balance the possible operational disincentive a poorly-organized CA might >> have against performing appropriate remediation. Even the prospect of >> distrust is remedial: if the CA can’t be trusted, they shouldn’t be trusted. >> >> What you’re proposing is that we add something punitive, which means >> that, I assume, you believe that we would need something to motivate action >> that the CA might otherwise not take without the prospect of that >> punishment. That motivational effect would not be equal across all CAs, >> which means that the calculus of be-careful-or-pay would not be a reliable >> means to get back to the important state: the WebPKI’s corpus of valid >> certificates being trustable *in all their details* by relying parties. (I >> think that the focus on there being some commercial element to issuance and >> trust would not age well either, given that a large and quickly-growing >> portion of the web’s certs are not issued on a commercial basis. Who would >> get credits from Microsoft for their recent misissuance? Another part of >> Microsoft?) >> >> And—I’m sorry this is so long, but whatever—the proposed punitive measure >> doesn’t even make the PKI whole! You would still have certs floating around >> with incorrect information, but the subscriber would have a trivial credit >> against their next webinar about automation. >> >> If it is in the CA’s interest to provide additional voluntary constraints >> on their issuance, then it is because it is somehow in their interest to do >> so. That could be because they are chartered to improve the security of the >> web (would that they all were, tbh), or to distinguish themselves in a >> competitive marketplace. They should not pursue those things in ways that >> undermine the fundamental guarantee of the WebPKI: the attributes of the >> certificate are true. Either way, those constraints don’t matter unless >> they can be relied on by RPs. And if they are to be relied on then they >> need to hold for all valid certificates, so… >> >> CAs can “maybe, we’ll try!” exceed BRs on their own initiative, without >> any interaction with the BRs or its remedial mechanisms; just don’t put it >> in the CPS. Maybe the CAB/F can give out ribbons for effort on the social >> event cruise, or provide badges for CAs to put on their web sites and in >> email signatures. “__321__ days since a commitment(*)-breaking issuance!” >> >> But, again, I think this is a molehill and not a mountain. At best an >> amusing distraction from pursuits that might actually *improve* the >> reliability of the WebPKI, rather than make it even more complicated for >> relying parties to navigate. >> >> Mike >> >> -- >> 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/CADQzZqvqrGfiFkK6f%3Dt6kD8VPwNpocBBdkYSNbOA3me12CG6UA%40mail.gmail.com >> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CADQzZqvqrGfiFkK6f%3Dt6kD8VPwNpocBBdkYSNbOA3me12CG6UA%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/CAFK%3DoS9AbLB5Q-Lk4N-%2BCJt6yF%2BgCoHsdMuOj7gYkwqiWSaSwQ%40mail.gmail.com.
