I agree that one of the possible approaches that Root Programs can employ would be a random set of certificates being revoked. 24 hours is a bit extreme for that though, I'd put forward 5 days as its the maximum time for a real issue to be handled.
Other potential levers I've considered that could be used but have a variety of different problems, just for consideration: 1. Add in extra limits for certificate lifespan, this will reduce the impact and add in pressure to improve processes. If we're moving to 90 days eventually then having non-complying CAs take the first step would be helpful for all 2. The random revoke/reissuance mentioned above, there's already a 3% audit so I don't see what the major barrier is for increasing this to revocation too - up the days to 15 for these and have that be an audited metric for successes in specific timeframes 3. If a CA is misbehaving then reducing what types of certificates they can issue would apply some pressure (i.e. no EVs will be trusted after x date until 3/6 months later), particularly if their issues are primarily in mishandling these certificate types 4. Policy-wise only allowing certificates that have been issued via automated means to subscribers' servers. We've had the excuse of automation peddled out enough, add in some pressure to force change there 5. Increase the self-reporting required to include which subscribers have received certificates, what their revocation means are, and whether they are using automation currently 6. If we're getting the critical infrastructure excuse time and time again, restrict a CA from handling these subscribers until they can consistently deal with less vital subscribers 7. At the extreme limiting what TLDs the CA can issue under, this is more a stepping stone to reducing root exposure across the board and would be policy until the technical measures are implemented 8. If problems are happening and the audits haven't noticed it then enforce additional an audit outside of the 'annual' interval by a company and personnel the CA hasn't used before 9. To help the industry more add in some requirements on implementing lints in zlint, etc. The CA should already be putting in resources into this area but this would be beneficial to the ecosystem as a penalty 10. Lastly a measure that would only be possible in a real regulated industry: bringing in personnel to oversee the CA's operations for 3/6 months directly that are employed by a regulatory body I'm aware that these are not all possible but inspiration is being brought in from what an actual regulated industry would do. Having a full distrust as the main mechanism for a CA to expect is only causing them to push the limits of what is acceptable practice while not seeming bad enough to earn all of their roots revoked. What the industry needs to do in response is apply pressure to ensure that less-severe measures are used regularly for non-compliance to ensure that resources are actually put into compliance and not sales. For revocation incidents I don't see what the barrier is for a final report to be generated by the CA of a list of their certificates that were due and when they actually happened. Care must be taken in ensuring that CAs are generating this data to show compliance, and not to generate excuses to push for slower and slower revocation deadlines however. This is part of why I included 30 days in my research and didn't only list 1/5/15 days. On Sunday, June 2, 2024 at 12:48:00 PM UTC+1 Jesper Kristensen wrote: > While I like the spirit in what you write, I think having a vague > requirement about a CA knowing a subscriber's intentions will just result > in an endless stream of incidents with arguments of subjective matters. I > think that would be a waste of the web PKI community's time and resources, > just like I think that the current requirement to not issue for weak keys > has taken more resources historically than the benefit provided by the > requirement. > > I can also very much relate to Tim's message. From my experience with > critical infrastructure, a change is not allowed with less than X weeks of > notice, unless we have done everything we could to avoid it. I would > interpret that policy to mean that we would only be allowed to replace a > certificate within 5 days or 24 hours if we had told the CA that we would > not be able to do it, and the CA had then told us that they would revoke on > time anyway. > > I think it is a problem that we only discuss these matters with CAs after > they had an incident that required revocation. > > People are bad at judging risks, just like how people rush to buy flood > insurance just after a major flood has happened, many subscribers will not > understand their obligations until their CA tells them that their > certificate is about to be revoked. > > I think the only way to improve is for these CAs to start revoking. Maybe > apply the principles of grease / chaos engineering. Maybe CAs should be > required to revoke a random set of certificates at random times with less > than 24 hours notice just to test the replacement process, or maybe CAs > should be required to hold a drill every year where they replace their > entire certificate population within 24 hours. > > Den fre. 24. maj 2024 kl. 22.58 skrev Mike Shaver <[email protected]>: > >> Hi; I hope this is the right list for these questions and discussion. >> Please feel free to redirect me to a more suitable venue if there should be >> one. >> >> TL;DR >> >> Is it permissible for a CA to issue a certificate to a Subscriber if they >> know that the Subscriber cannot fulfill the warranties and acknowledgements >> from section 9.6.3 of the BRs, such as Subscribers who are not able to >> “accept” or tolerate revocation along the BR’s timelines? >> >> CONTEXT >> >> Section 9.6.3 of the TLS BRs (version 2.0.4) deals with Subscriber >> warranties and acknowledgments. I reproduce the preamble below, which is >> followed in the document by a list of such warranties and acknowledgements, >> with apologies for the length: >> >> *The CA SHALL require, as part of the Subscriber Agreement or Terms of >> Use, that the Applicant make the commitments and warranties in this section >> for the benefit of the CA and the Certificate Beneficiaries. Prior to the >> issuance of a Certificate, the CA SHALL obtain, for the express benefit of >> the CA and the Certificate Beneficiaries, either:* >> *1. The Applicant’s agreement to the Subscriber Agreement with the CA, or* >> *2. The Applicant’s acknowledgement of the Terms of Use.* >> *The CA SHALL implement a process to ensure that each Subscriber >> Agreement or Terms of Use is legally enforceable against the Applicant. In >> either case, the Agreement MUST apply to the Certificate to be issued >> pursuant to the certificate request. The CA MAY use an electronic or >> “click‐through” Agreement provided that the CA has determined that such >> agreements are legally enforceable. A separate Agreement MAY be used for >> each certificate request, or a single Agreement MAY be used to cover >> multiple future certificate requests and the resulting Certificates, so >> long as each Certificate that the CA issues to the Applicant is clearly >> covered by that Subscriber Agreement or Terms of Use. The Subscriber >> Agreement or Terms of Use MUST contain provisions imposing on the Applicant >> itself (or made by the Applicant on behalf of its principal or agent under >> a subcontractor or hosting service relationship) the following obligations >> and warranties:* >> >> Item 8 in the list is as follows: >> >> *8. Acknowledgment and Acceptance: An acknowledgment and acceptance that >> the CA is entitled to revoke the certificate immediately if the Applicant >> were to violate the terms of the Subscriber Agreement or Terms of Use or if >> revocation is required by the CA’s CP, CPS, or these Baseline Requirements.* >> >> CONCERN >> >> I draw attention to this requirement, which must be legally binding upon >> the Subscriber, because there have been *many* incident reports in Bugzilla >> describing delayed revocation caused by a Subscriber’s inability (or >> unwillingness to invest sufficiently) to replace a misissued certificate >> within the 24-hour window, or even the recently-extended 5-day window. >> Furthermore, the services to which these certificates are deployed are >> described as “critical infrastructure”, or the CA claims that revocation >> would be “disruptive to the web ecosystem”. From the descriptions provided >> by the CAs, it seems that due to the context in which the subscribers >> operate (government, health, banking, travel) the CAs in question >> *expected* that these Subscribers would not be willing to replace >> certificates within the well-known and agreed-to BR deadlines. >> >> By my understanding of the BRs, no CAs should be issuing certificates to >> Subscribers if they know that the Subscriber’s acknowledgement and >> acceptance of point 8 is untrue. Many CA’s CPSs also prohibit use of their >> certificates in contexts that may lead to loss of life, human injury, or >> substantial financial loss. (Surprisingly, some don’t, which I understand >> to mean that they warrant the certificate’s suitability for life-critical >> applications?) >> >> QUESTIONS >> >> What is the understanding of this group? Is it permissible for a CA to >> issue a certificate to a Subscriber when they know that this Subscriber >> does not, in fact, acknowledge and accept item 8? If CAs are to work with >> Subscribers to help those Subscribers tolerate immediate revocation as per >> the BRs, I believe that this work should happen *before* a certificate is >> issued, not in the wake of a misissuance. (What would happen if there were >> a key compromise? WebPKI is used for many important things, but I don’t >> think it is appropriate for contexts where loss of CA or Subscriber key >> material could result in intolerable consequences for society and the web.) >> >> As a minor follow-up question, would it be permissible for a CA to >> provide a guarantee to a Subscriber that may require the CA to violate the >> BRs? For example, could a CA contractually warrant to a Subscriber that the >> Subscriber would have 30 days to replace before revocation? >> >> Thank you for your time and consideration, and all the work you do to >> keep the WebPKI healthy for its primary constituents: users of the web. >> >> Mike >> >> -- >> You received this message because you are subscribed to the Google Groups >> "CCADB Public" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> > To view this discussion on the web visit >> https://groups.google.com/a/ccadb.org/d/msgid/public/CADQzZqv-6M-t0FYr0cHkzEeo-mWzVj-Db9wmEaoTU2Esy6RrWw%40mail.gmail.com >> >> <https://groups.google.com/a/ccadb.org/d/msgid/public/CADQzZqv-6M-t0FYr0cHkzEeo-mWzVj-Db9wmEaoTU2Esy6RrWw%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "CCADB Public" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/ccadb.org/d/msgid/public/c51453d5-89a2-4cc3-85c5-a72a8ef024c1n%40ccadb.org.
