The specific CP/CPS concerns that I identified have been addressed in the latest version of these documents (attached to bug #1341604).
Some of the misissuances [1] have been addressed - in particular, the 10 "dedicated server application software certificates" have been revoked and replaced with certificates that are beyond the scope of the Mozilla program because they assert a custom EKU OID. Some of the certificates listed in [1] are still unrevoked, including: * missing stateOrProvince or localityName * organizationName or organizationalUnitName > 64 characters Chunghwa Telecom did provide a detailed response [2] explaining their position on each of these issues and stating that they will no longer issue certificates containing these errors. Other than the two "mistakes" identified and revoked by Chunghwa Telecom [3], no misissuances have been detected since 5-May. This discussion began on 18-May. I would like ask to everyone to post any comments you have on this request to include the Chunghwa Telecom eCA root certificate (ePKI Root Certification Authority - G2) no later than Monday 16-July. - Wayne [1] https://crt.sh/?CAID=1770&opt=cablint,zlint,x509lint&minNotBefore=2015-01-01 [2] https://bug1341604.bmoattachments.org/attachment.cgi?id=8974418 [3] https://bug1341604.bmoattachments.org/attachment.cgi?id=8974418#c66 On Tue, Jul 10, 2018 at 7:58 AM lcchen.cissp--- via dev-security-policy < [email protected]> wrote: > [email protected]於 2018年6月5日星期二 UTC+8下午5時22分40秒寫道： > > Wayne Thayer於 2018年5月19日星期六 UTC+8上午8時13分15秒寫道： > > > This request is for inclusion of the Chunghwa Telecom eCA as > documented in > > > the following bug: > https://bugzilla.mozilla.org/show_bug.cgi?id=1341604 > > > > > > > > > > > ==Bad== > > > * A large number of certificates have been misissued from the “Public > > > Certification Authority - G2” intermediate [1] (recent example: [2]). > Many > > > of these certificates remain valid. Chunghwa Telecom has published a > > > response to these errors [3] in the inclusion bug. My main concern > with the > > > response is the assertion that some of these are not SSL certificates > bound > > > to follow the BRs because they do not contain the CAB Forum OV OID in > the > > > certificate policies extension. This assertion contradicts section 1.1 > of > > > Mozilla policy. > > > > > > This begins the 3-week comment period for this request [4]. > > > > > > I will greatly appreciate your thoughtful and constructive feedback on > the > > > acceptance of this root into the Mozilla CA program. > > > > > > - Wayne > > > > > > [1] > > > > https://crt.sh/?CAID=1770&opt=cablint,zlint,x509lint&minNotBefore=2015-01-01 > > > [2] https://crt.sh/?id=290793483&opt=zlint,cablint,x509lint > > > [3] https://bug1341604.bmoattachments.org/attachment.cgi?id=8974418 > > > [4] https://wiki.mozilla.org/CA/Application_Process > > > > Dear Wayne, > > > > We have already paused the issuance of this type of certificate in > argue, i.e., dedicated server application software certificate. > > > > There are 10 such type of certificates that are still valid, as > listed in https://bugzilla.mozilla.org/attachment.cgi?id=8983333. > > > > By the way, the certificate of 綠金石平台( > https://crt.sh/?id=290793483&opt=zlint,cablint,x509lint) that Mozilla > mentioned in Ref [2] of Comment 55 of > https://bugzilla.mozilla.org/show_bug.cgi?id=1341604 was revoked on May > 21th this year, and hence not listed in this attached file. > > > > All these 10 certificates are used by the systems owned by our > company, i.e., Chunghwa Telecom Co., Ltd.. > > > > Although these 10 certificates have a SubjectAltnativeName that > includes DNSName, they are never used as SSL certificates. Here are our > solutions for handling these 10 certificates. > > > > 1. We plan to modify the format of this type of certificate. The new > certificate format will contain an EKU that excludes anyPolicy, > emailProtection and serverAuth; besides, there will be no SubjectAltName > anymore. In other words, neither DNSName nor IPAddress will be included in > this type of certificate. > > > > 2. We plan to notify the owners of the 10 certificates to make an > application for revoking their original certificates and re-issuing a new > one according to the new format. > > > > After discussing with the owners of the 10 dedicated server > application software certificates, they are all willing to re-issue these > certificates with the new format and revoke the old ones. However, before > that we still have some work to do, such as system modification, electronic > process, and so on. > > > > We plan to finish the re-issuing and revocation processes of all > these 10 certificates before early July. Of course we will also report > immediately if we finish that in advance. > > > > Thank you. > > > > Sincerely Yours, > > > > Li-Chun > > > > Dear Wayne, > > After re-issuing and testing the new certificates with the new format > by those applications, the rest 5 proprietary server application software > certificates [1] are also revoked. > > So we update the information for these certificates in the attached > file (https://bugzilla.mozilla.org/attachment.cgi?id=8991008) > > As you can see in that file, all the Status column are already marked > as ‘revoked’ with the revocation time in the parentheses. > > Besides, the information of the new certificates with the new format > are specified in the New Certificate column. > > We also provide these new certificates as attached zip fil( > https://bugzilla.mozilla.org/attachment.cgi?id=8991015) for your > reference. > > [1]We call them "dedicated server application software certificates" > before, but these certificates are using propriety protocol (unlike TLS > protocol, are widely using protocol). After discussing with my colleague > and you, we call them "proprietary server application software > certificates" to communicate the fact that these certificates are not for > SSL and are not BR-compliant. > > > Sincerely Yours, > > Li-Chun > _______________________________________________ > 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
