Hi all, TL;DR: We’re willing to consider moving the key freshness requirement from 5 years to 3 in a future policy update. Reducing the key-freshness requirement was always part of our long-term strategy.
Dimitris’ use-case description is what we were hoping to accommodate. We’ve seen key generation audit reports where over 50 keys were generated at once, with the specific acknowledgment that the keys were created for future use (i.e., “parked”). Even a year after generation, we do not observe the corresponding public key included in publicly-available certificates (or, by extension, public root program application queues). We’ve even observed an audit report that included over 150 keys. To be clear, this is not a commentary on this practice; I’m simply highlighting the existence of the use case described by Dimitris. In any event, our long-term plan before Ben’s post was to reduce the “key-freshness” requirement introduced in our V1.1 policy update. One of the reasons we did not initially require a shorter key-freshness period was because we recognize the effort, cost, and time commitment required by CAs to apply to root programs - and ultimately become “publicly trusted.” Imposing a more strict key-freshness requirement when one did not previously exist in any public root program policy would have resulted in additional churn by CA owners observed in other public root program application queues without guaranteed security value. So, ultimately, we chose five years to balance practical security goals (described below) and the planned launch of our program, with a longer-term goal of eventually reducing this period after better understanding the impact on applicants. We value the use of “fresh” key material because: - When coupled with our future proposed <https://www.chromium.org/Home/chromium-security/root-ca-policy/moving-forward-together/#encouraging-modern-infrastructures-and-agility> CA term limit, it establishes a ceiling for the maximum time a key that has been unknowingly compromised could impact the security of Chrome’s users. - The Baseline Requirements and audit schemes permitted therein have been continuously improving since their inception. Aligning with modern requirements, practices, and audit frameworks is the only way of benefiting from that improvement. For example, WebTrust’s lifecycle management audit as we know it today wasn’t established until 2019 <https://cabforum.org/wp-content/uploads/22.-Webtrust-CABF-update-June-13.pdf> . - Similar to the Baseline Requirements and corresponding audit schemes, the same continuous improvement is true for the software libraries and systems that generate and protect key material. - As above, it allows the ecosystem to realize the benefits of continuous improvement efforts made by CAs regarding the ongoing management of key generation scripts and ceremonies. - It promotes agility. - Being well-versed and well-rehearsed in performing key generation ceremonies will prepare us better for the future (i.e., preparing for a “post-quantum” world where we may quickly need to instantiate new CAs). Related to this issue, in a future policy update, we may clarify our expectations regarding how “parked keys” must be audited and represented in audit statements, similar to the structured reporting format required for CA certificates (see Section 8.6 of the BRs). Thanks, and please let me know if there are any questions! - Ryan [on behalf of the Chrome Root Program] On Thu, Sep 8, 2022 at 3:13 AM Dimitris Zacharopoulos <ji...@it.auth.gr> wrote: > > > On 8/9/2022 2:02 π.μ., Ben Wilson wrote: > > Hi Dimitris, > Thanks. I don't know why Chrome chose five years because I can't think of > a scenario where a CA operator would take 4-5 years to submit their root CA > for inclusion in the trust store. Whereas, three years seemed more > reasonable and manageable. > > > Without being 100% certain, I believe there is a use case where a CA > performs a key generation ceremony witnessed by an external Qualified > auditor, then "park" those keys making sure they are covered in annual > audits by providing "key protection" audit reports for the keys not > associated with Root CAs. This has been presented in CABF F2F meetings > several times. I assume that a CA with "parked keys" could pick some of > those keys up 4 years from creation and create a Root CA(s) to be included > in Root stores without needing to perform another (costly?) keygen > witnessed by an external auditor. > > Either way, I'm more concerned about the deviation from the Chrome Root > Store Policy than the decision of 3 or 5 years :) Hopefully the two > programs can align (either Chrome change to 3 years or Mozilla change to 5). > > > Dimitris. > > Ben > > On Tue, Aug 30, 2022 at 12:39 PM Dimitris Zacharopoulos <ji...@it.auth.gr> > wrote: > >> >> >> On 16/8/2022 12:28 π.μ., Ben Wilson wrote: >> >> Addition to: Section 7.1 Inclusions >> >> CA key material MUST be generated within the three (3) years that precede >> the submission of a CA inclusion request. The date of CA key material >> generation shall be determined by reference to the auditor’s key generation >> ceremony report. >> >> >> Why 3 years instead of 5? What are the security benefits of a key being >> generated 3 vs 5 years ago? The Chrome Root Program Policy states that it >> will accept keys generated 5 years ago so perhaps there is no significant >> reason to justify this policy divergence. >> >> >> Thanks, >> Dimitris. >> -- >> 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 on the web visit >> https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/7583f738-82f3-cd1b-3793-5254e4d83095%40it.auth.gr >> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/7583f738-82f3-cd1b-3793-5254e4d83095%40it.auth.gr?utm_medium=email&utm_source=footer> >> . >> > > -- > 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 on the web visit > https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/5dbe5339-b106-cc73-4c58-22c76dd39486%40it.auth.gr > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/5dbe5339-b106-cc73-4c58-22c76dd39486%40it.auth.gr?utm_medium=email&utm_source=footer> > . > -- 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 on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CADEW5O-b_j_fbngV7so9OfjecZSSLMO-m-dBqhcge%3DAnrk6BWw%40mail.gmail.com.
