> 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.
They don't, but what is the incentive of the CA to give the relying party more protection while risking revocation if someone writes the information incorrectly. We are in violent agreement that the certificate would be mis-issued if the CPS was incorrect though and that revocation is the correct way to address that. > 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. Yeah - definitely agree with you here. That's the problem with coming up with a solution. Any error in the CPS means teh promise was completely empty nor can the relying party trust any other part of the CPS in that case. The CA could be lying about those whole CPS document if you allow the CA to determine what constitutes a typo vs. any other error. > 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). Sure. I agree with that as well, but I also don't think it addresses the issue of diminishing transparency in CPS docs. Not all, but a lot of them read like they are the BRs. > 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. Yeah - no disagreement here. It's also a long established rule that CAs aren't allowed to make "its not a security issue" arguments with bugs. Similar item applies here. My dislike of the current CPS process is two fold: 1) it encourages copying and pasting the BRs instead of giving the community extra transparency on what is going on. The extra transparency always happens around bugs instead of before them. I think it would be far better if CAs could include architecture diagrams, process flows, and similar information for the browser/RP review that avoids the marketing gloss that gets put on many public documents. 2) Some human is expected to write this document and get it right. We should encourage more automated CPS document creation where practices are pulled from systems rather than having a person write what the system is doing. On Thu, Jun 5, 2025 at 2:12 PM Mike Shaver <[email protected]> wrote: > 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/CAFK%3DoS9Dr3EoUhOmdfnYpuFSAVypxdq_nuhrVx0uz_D30sA7VA%40mail.gmail.com.
