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%3DoS9jVu4FH7wEmw841JjJs1VyfA9U1SKGjPQEW2Wzzefbyw%40mail.gmail.com.
