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 <dev-security-policy-boun...@lists.mozilla.org> On Behalf Of Wayne Thayer via dev-security-policy Sent: Wednesday, October 2, 2019 6:05 PM To: horn...@gmail.com Cc: mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org> 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 < dev-security-policy@lists.mozilla.org> 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 dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
