All, For the sake of uniformity, I think we're willing to synchronize with the Chrome 5-year limit on key generation. I'll make that change for the next version announced. Ben
On Fri, Sep 9, 2022 at 6:56 AM Ryan Dickson <[email protected]> wrote: > 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 <[email protected]> > 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 <[email protected]> >> 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 "[email protected]" 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/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 >> "[email protected]" 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/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 "[email protected]" 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/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaZtezpbtYuuZZ9PDdF7BkDx4D8x4sGoZ47fce6FfMA0JA%40mail.gmail.com.
