I agree with all of these points. As for 3, there are some inexpensive ways we could get to this end-state state if any CA is interested in discussing this please reach out.
FWIW this thread inspired me to write up this post: https://unmitigatedrisk.com/?p=1041 On Fri, Jun 13, 2025 at 7:22 AM Jeremy Rowley <rowley...@gmail.com> wrote: > 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 <rowley...@gmail.com> 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 <mike.sha...@gmail.com> >> wrote: >> >>> On Fri, Jun 13, 2025 at 5:58 AM Tobias S. Josefowitz <to...@opera.com> >>> 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 "dev-security-policy@mozilla.org" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to dev-security-policy+unsubscr...@mozilla.org. >>> 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 " > dev-security-policy@mozilla.org" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to dev-security-policy+unsubscr...@mozilla.org. > 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 > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAFK%3DoS9AbLB5Q-Lk4N-%2BCJt6yF%2BgCoHsdMuOj7gYkwqiWSaSwQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "dev-security-policy@mozilla.org" group. To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-policy+unsubscr...@mozilla.org. To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CALVZKwbh1t-i4R73yQLn27%3DhuXtmAXV-Dz3ZXUx--tEO4PHc%3DQ%40mail.gmail.com.
