Also concurring with Ryan, excellent summary of the issues. I'd like to emphasize the seemingly forgotten detail whenever a CP/S a discussed: it is a legal document. It discusses the technical controls, certificate profiles, and contractual bindings between subscriber and CA. The kneejerk reaction to attempt to rewrite this is showing an inherent misunderstanding of what the CP/S documents are, and very much seems like people trying to rush a solution without following considering the problems.
If we take a step back is the issue really where the boundaries of contract law and technical documents crosses over, or is it down to mass revocation plans? I've been thinking of this during the ongoing Microsoft incident, but is there a particular reason we lack an arbitrary maximum number of live certificates per intermediary? We lack actual hard figures on client limitations for CRL processing, CRP were pointing out active CRLs far exceeding the 10MB figure. A carve-out for short-lived certs, and planning from the worst-cast of a full revocation event what would be the ideal threshold for maximum number of certs? I'm not proposing this for BRs, or as a Root Program requirement - but certainly an option to minimize the blast radius for higher-level key compromise scenarios. - Wayne On Thursday, June 5, 2025 at 9:12:59 PM UTC+1 Mike Shaver wrote: > On Thu, Jun 5, 2025 at 3:54 PM Jeremy Rowley <rowl...@gmail.com> 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 "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/1f91238d-b5c0-4efc-b2e1-9d4c12c0f113n%40mozilla.org.
