On Thu, Jun 5, 2025 at 3:54 PM Jeremy Rowley <[email protected]> wrote:
> Hi Mike, > > I didn't hear any disagreement on the call that the current policy > mandates revocation for a CPS misalignment. I'm also not sure that the > conversation was about Microsoft as that was a cert profile question, not > just a typo. > I am mixing my venues, apologies. Microsoft's CPS error has been described (minimized) as "a typo" elsewhere, and I inappropriately carried that over to this discussion. My apologies to the readers and to Microsoft. > 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. > This doesn't make sense to me. Many of the items in CPSes (whether they exceed the BRs or not) are commitments to the relying party about how the certs are generated or protected. And it's for things that aid the relying parties that I want to see CAs exceed the BRs in the first place: tighter controls, shorter validity, etc. How does a relying party "get a credit" if they rely on a certificate property specified in the CPS that turns out to not hold, because the CPS was incorrect? That certificate will continue to carry the misleading characteristic for the duration of its validity, which is why we want to see its validity terminated. The CA *isn't* doing more than the BRs if relying parties can't expect that those extra things apply to every certificate claiming so. They're *trying* to do more, and *maybe* you can trust that a given certificate has the properties that its linked CPS claims. If the CPS isn't a reliable reference for the practices under which the certificate was issued, then let's take that link out of the certificate entirely and replace it with inline fields for whatever "important" (read: revocation-worthy if mismanaged) attributes are needed. The right path isn't to make CPS errors into "diet incidents" distinct from other errors related to attributes of certificate issuance. It's to make revocation simple and painless so that we don't have CAs "forced" to delay the revocation of millions of inaccurate certificates, due to a failure to implement best practices advocated by their own organization (like CRL sharding). I'm referencing Microsoft here again because they are a fresh example, but they are definitely not alone in having cases of delayed revocation that were preventable through diligent application of the practices the community has learned through painful lessons. We heard the same "it is a wafer-thin error, don't make us do the thing for which we have ill-prepared ourselves and our Subscribers" complaint about country codes and OIDs and fields being lowercase or uppercase--basically anything else that isn't a straight-up key material leak. The underlying principle remains the same: if it's not important, don't put it (including by reference) in the certificate in the first place. But the *entire point* of the dance we do with CAs and CT and validity restrictions and revocation and paid-for-by-the-auditee-but-that's-another-thread WebTrust audits and *even having BRs* is this: relying parties can rely on the assertions made by the certificate if it is valid and the issuance chain can be verified. If that's not going to hold, then there really is no point and we can let ssh-style cert continuity suffice for the web instead. 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/CADQzZqvU14rQKsBEvs1ic1rD1H5dmzSn12G1YLdf0Ds%2Bi%2B8E7g%40mail.gmail.com.
