Hi Amir - I'm one of the people who mentioned ACME on the call. I've been doing a lot of ACME related setups lately. It works wonderfully for server devices but non-servers (like firewalls) are a pain. They require my team to write scripts into the API to get the system working correctly. I don't think this is an IETF problem but a device manufacturer problem where we need to encourage better ACME adoption for non-traditional servers.
For example, I set up a website with ACME that worked wonderfully. However, when I went to get my firewall set up with the same cert, I couldn't automate the thing. Because I couldn't get the firewall to work with ACME, I only got have my system automated. On Thu, Jun 5, 2025 at 2:24 PM Jeremy Rowley <[email protected]> wrote: > > 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%3DoS_PpqtLUfLWrQvE4_7TzFq8dj%2BK9rhpuVurhhypUVam4g%40mail.gmail.com.
