In bug 1523221 , 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  without creating interoperability problems .
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.
== 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
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
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
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
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
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
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
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
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