Yeah - that's correct and you aren't missing anything. This is a distribution problem only. The call to action I was hoping to achieve by bringing it up was to encourage more communication (for everyone) about the impact of moving to 45 day certs and the need for automation. For example, CAs should be demanding that HSM providers support ACME and short lived certs. Despite CAs being a big customer, most HSMs don't support great automation.
On Thu, Jun 5, 2025 at 3:13 PM Amir Omidi <[email protected]> wrote: > Hi there! > > This seems like it's a certificate distribution problem, rather than an > automation problem. I don't think there is any solution that can be made at > the CCADB or root program level which would solve this problem? Maybe the > issue is short lived certs, rather than requirement of automation? > > This is an issue folks have to deal with today, and realistically the > option here is that you either work with the vendor to build in support for > a protocol like ACME or write a few hundred lines of shell script to do the > issuance on a separate machine and then load it onto the firewall. > > Am I missing something here? > > On Thu, Jun 5, 2025 at 1:29 PM Jeremy Rowley <[email protected]> wrote: > >> 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%3DoS8c-CdKu8h6k6FyKpjE0bc5AJ7v5C%3DYmYpcQWi0siRf2A%40mail.gmail.com.
