In bug 1523221 [1], GRCA (Government of Taiwan) has responded to a misissuance report by stating that the certificates in question are not intended for serverAuth or emailProtection. However, our policy applies to certificates **capable** of being used for serverAuth or emailProtection, including those that omit an EKU extension. GRCA acknowledges this fact, but has stated that these are document signing certificates, and there are no standardized EKUs for document signing that they could use to constrain these certificates [2] without creating interoperability problems [3].
GRCA has now filed an incident report [4 and below] in which they have proposed a timeline for moving away from this practice that has them issuing unconstrained certificates that do not comply with the BRs until the end of 2020. Presumably it would be years longer before these certificates have all expired. I would appreciate everyone's input on this issue and the proposed solution. - Wayne [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1523221 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1523221#c4 [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1523221#c7 [4] https://bugzilla.mozilla.org/attachment.cgi?id=9051175 == Incident Report == 1. How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, a discussion in mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and the time and date. Taiwan Government PKI has been developed for more than 10 years. Government PKI and various e-Government applications strictly follow RFC 5280 and the original ITU-T X.509 standard for certificate format and Validation method. However, the current use of the extended field of EKU by Browsers on Web PKI is inconsistent with the original definitions in RFC 5280 and ITU-T X.509 (please refer to https://mailarchive.ietf.org/arch/msg/pkix/aYpt23Ea4Ey5nB4kR6QfyND4SPk), and our Government PKI existed before the definition of the so-called Web PKI and the new usage of EKU invented by various Browsers. Taiwan Government joined the restriction of EKU in SSL certificates in 2018, but unfortunately each of the Browsers still forces our Government PKI to add EKUs to Citizen Certificates other than SSL certificates (the number of these certificates exceeds 4 million), even if these Citizens Certificates are not considered by Browsers to be SSL/TLS Certificates in terms of format and technique. And there is currently no international standard defined General-Purposed Signing/Encryption EKU OID can be used, and this topic was also discussed in the 42nd CABForum at F2F meeting on 2017/10/3 - 2017/10/5 (please refer to https://cabforum.org/2017/10/04/2017-10-04-minutes-face-face-meeting-42-taipei/#Determine-Applicability-of-Certificates-by-using-standard-CABF-CP-OIDs), but so far there is no conclusion. This issue was again raised in Bugzilla on January 27, 2019 (Bug 1523221), and we responded immediately, but Mozilla still required that all other non-SSL certificates must add the EKU. 2. A timeline of the actions your CA took in response. A timeline is a date-and-time-stamped sequence of all relevant events. This may include events before the incident was reported, such as when a particular requirement became applicable, or a document changed, or a bug was introduced, or an audit was done. March 3, 2003: GCA was established 2015年??月??日: GCA配合於SSL類憑證加入EKU January, 2015: GCA added EKU into SSL certificates accordingly. October 3, 2017: The use of EKUs was discussed at the 42nd CAB Forum at F2F meeting, but no consensus was reached at the meeting. January 27, 2019: The issue of non-SSL certificates issued by GCA without the EKU was raised in Bugzilla (Bug 1523221) and began to respond. February 19, 2019: Mozilla still believes that the certificate was mis-issued and requested an incident report. February 25, 2019: Discussed with the National Development Council of ROC and decided to join the Mozilla Policy to include EKUs in non-SSL user certificates. January 1, 2021: Officially add EKU to non-SSL user certificates 3. Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem. A statement that you have will be considered a pledge to the community; a statement that you have not requires an explanation. Taiwan Government began to issue user certificates in 2003 and issued certificates in accordance with RFC 5280 and the original ITU-T X.509 standard. At that time, there was no such requirement to use EKU, and it still works according to the standard. Therefore, in addition to SSL certificates, other non-SSL class certificates have not added EKUs to the user certificates. In line with the Mozilla Policy, our GPKI authorities have agreed to include EKUs in all non-SSL user certificates. However, due to the development of PKI in Taiwan for many years, the number of users (more than 4 million valid certificates) and the number of electronic government application systems related to certificates (more than 2,000 application systems), the influence range of implementation is very large, and all subordinate CAs and application system’s owners need to be coordinated, which is costly and requires a long time. Therefore, after multiple evaluations, it is decided to officially add the EKU to the user certificate on January 1, 2021. 4. A summary of the problematic certificates. For each problem: number of certs, and the date the first and last certs with that problem were issued. As mentioned in the 3rd point, Taiwan Government has not applied EKU to non-SSL user certificates/credentials. At this point in time, it can only be confirmed that the last user certificate without EKU will be issued on December 31st, 2020. 5. The complete certificate data for the problematic certificates. The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem. Since there are more than 4 million user certificate/credentials without EKU (also those are not the SSL/TLS certificates), they would not be uploaded to CT, and it is not possible to provide the list directly due to the huge amount. 6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now. As mentioned in the 1st point, Taiwan Government’s early development of PKI was in accordance with the RFC 5280 and the original ITU-T X.509 standard. Later on, the BROWSERS has different definition of the use of EKU on Web PKI rather than what was originally defined in RFC 5280 and ITU-T X. Also without any current information on how the International standards define the General-Purposed Signing/Encryption EKU OID, what was mentioned above causes the problem. Taiwan Government has applied EKU to the SSL certificates, although the non-SSL ones are not. However, those Citizens Certificates would not be mistaken for the SSL/TLS Certificates (in formatting) by the BROWSERS technically. 7. List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things. February 25th, 2019: discussed with the GPKI authorities in Taiwan and decided to apply EKU to non-SSL user certificates followed by Mozilla’s policy. May, 2019: will meet with GPKI subordinate CAs for clarification August, 2019: will host sessions to explain with the authority of the voucher application systems September, 2019 ~ December, 2020: will apply system modification to all voucher application systems January 1st, 2021: will apply EKU to all non-SSL user certificates officially _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
