I've gone ahead and moved the effective date of this policy back to July 1, 2020: https://github.com/mozilla/pkipolicy/commit/7a879fe371844d265c484a8f0ce40fd255967c13
On Wed, Oct 2, 2019 at 6:04 PM Jeremy Rowley <[email protected]> wrote: > I'm surprised any CA has heartburn over the EKU changes. Microsoft has > required them in end entity certificates for quite some time. From the MS > policy: "Effective February 1, 2017, all end-entity certificates must > contain the EKU for the purpose that the CA issued the certificate to the > customer, and the end-entity certificate may not use “any EKU.”" There's a > chance that the CA is not in Microsoft, but I thought Mozilla usually had > fewer CAs than Microsoft included. > > -----Original Message----- > From: dev-security-policy <[email protected]> > On Behalf Of Wayne Thayer via dev-security-policy > Sent: Wednesday, October 2, 2019 6:05 PM > To: [email protected] > Cc: mozilla-dev-security-policy < > [email protected]> > Subject: Re: Policy 2.7 Proposal: Require EKUs in End-Entity Certificates > > On Tue, Jul 9, 2019 at 2:12 AM horn917--- via dev-security-policy < > [email protected]> wrote: > > > Wayne Thayer於 2019年3月30日星期六 UTC+8上午4時48分27秒寫道： > > > The BRs require EKUs in leaf TLS certs, but there is no equivalent > > > requirement for S/MIME certificates. This leads to confusion such as > > > [1] > > in > > > which certificates that are not intended for TLS or S/MIME fall > > > within > > the > > > scope of our policies. > > > > > > Simply requiring EKUs in S/MIME certificates won't solve the problem > > unless > > > we are willing to exempt certificates without an EKU from our > > > policies, > > and > > > doing that would create a rather obvious loophole for issuing S/MIME > > > certificates that don't adhere to our policies. > > > > > > The proposed solution is to require EKUs in all certificates that > > > chain > > up > > > to roots in our program, starting on some future effective date (e.g. > > April > > > 1, 2020). This has the potential to cause some compatibility > > > problems > > that > > > would be difficult to measure and assess. Before drafting language > > > for > > this > > > proposal, I would like to gauge everyone's support for this proposal. > > > > > > Alternately, we could easily argue that section 1.1 of our existing > > policy > > > already makes it clear that CAs must include EKUs other than > > > id-kp-serverAuth and id-kp-emailProtection in certificates that they > > > wish to remain out of scope for our policies. > > > > > > This is https://github.com/mozilla/pkipolicy/issues/163 > > > > > > I will greatly appreciate everyone's input on this topic. > > > > > > - Wayne > > > > > > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1523221 > > > > > > GPKI(Taiwan) will follow Mozilla policy to add EKU to EE certificates > > However, the influence range of implementation is very large. > > We need to define our own Document Signing EKU and data encryption > > EKU, and coordinate all subordinate Cas(Five CAs) and application > > system’s owners(more than 2,000 application systems). > > It needs a whole year to implement this. Therefore, after multiple > > evaluations, it is decided to officially add the EKU to the user > > certificate on January 1, 2021. > > It is difficult for us to complete ahead of April 2020. > > Can we get more buffer? > > > > > I had expected to have this policy update completed sooner when I proposed > April 2020 as the date for requiring EKUs in end-entity certificates. Given > that, I think it's reasonable to push the date back to July 2020, but not > to January 2021. 2021 seems particularly unreasonable in light of the > Microsoft requirement [1] that went into effect in January 2017 and appears > to apply to GPKI. > > Will any other CAs find it impossible to meet this requirement for > certificates issued after June 2020? Also, are there any concerns with this > applying to certificates issued from technically constrained intermediate > CA certificates? As-proposed, this applies to those certificates (and it > appears to me that Microsoft's policy does as well). > > - Wayne > > [1] > > https://docs.microsoft.com/en-us/security/trusted-root/program-requirements#4-program-technical-requirements > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
