While sending a message that non-compliance could result in policy change is generally a bad idea, I did notice something about the profile of the non-compliant certificate which gave me pause:
None of the example certificates which were provided include a SAN extension at all. Today, no valid certificates for the WebPKI lack a SAN extension. There should always been at least one SAN dnsName, SAN ipAddress, or in case of S/MIME certificates, a SAN rfc822 name. I know that Chrome has already fully deprecated non-SAN bearing certs. Have the other browsers? I'm wondering whether it's possible or reasonable for policy to update such that certificates that lack any SAN at all would be out of scope? On Sat, Mar 16, 2019 at 6:42 PM Matthew Hardeman <mharde...@gmail.com> wrote: > I think answers to the following questions might be helpful: > > 1. What software / types of software are being utilized which would give > compatibility issues? What is the validation logic of those applications / > systems? > > 2. If these certificates don't have a purpose known to or respected by > the WebPKI, why must they be issued from a trust hierarchy which delegates > trust within the WebPKI? > > 3. If there are outside systems that want to see these certificates chain > to existing roots, perhaps a new SubCA could be spun up with an intention, > from the very start, of being OneCRL listed? (In other words, special > agreement from the root programs that this particular subCA is invalid in > the browsers, but remains unrevoked in the Root CA's CRL?) Obviously this > would require buy-in from the root programs as well as the CA, but maybe > it's a compromise that could be worked out? > > 4. What if they got a little innovative? Is there any chance they could > require that each of these certificates be issued with a subject including > an email address which has been validated to the standards the programs > require? Then set the client auth and email protection EKUs? They could > even provide the email addresses in question temporarily on a domain they > own, if needed. Would that still result in compatibility issues? > > 5. Other document signing programs exist and have existed for a long > time. It's a bigger thing in Europe, right? What's unique about this > situation that causes this non-compliance but that hasn't resulted in > non-compliance there? > > On Sat, Mar 16, 2019 at 6:02 PM Wayne Thayer via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> 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 >> > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
