Chunghwa Telecom eCA Root Inclusion Request

[Wayne Thayer]

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

* BR Self Assessment is here:
https://bugzilla.mozilla.org/attachment.cgi?id=8963172

* Summary of Information Gathered and Verified:
https://bug1341604.bmoattachments.org/attachment.cgi?id=8960397

* Root Certificate Download URL: http://eca.hinet.net/download/eCA2.cer

* CP/CPS:
** Root CP: http://eca.hinet.net/download/ePKI_CP_v1.5(Eng).pdf
** Root CPS: https://bug1341604.bmoattachments.org/attachment.cgi?id=8961804
** Public (DV, OV) intermediate CPS:
https://bug1341604.bmoattachments.org/attachment.cgi?id=8961805
** EV intermediate CPS:
https://bug1341604.bmoattachments.org/attachment.cgi?id=8961812

* This request is to turn on the Websites and Email trust bits. EV
treatment is requested.

* EV Policy OID: 2.23.140.1.1

* Test Websites:
** Valid: https://ev.hinet.net/
** Expired: https://ra.testev.hinet.net/
** Revoked: https://testev.hinet.net/

* CRL URL: http://repository.ev.hinet.net/crl/EVSSL/complete.crl

* OCSP URL: http://ocsp.ev.hinet.net/OCSP/ocsp

* Audit: Annual audits are performed by SunRise CPAs / DFK International
according to the WebTrust for CA, BR, and EV audit criteria.
** WebTrust: https://cert.webtrust.org/SealFile?seal=2306&file=pdf
** BR: https://cert.webtrust.org/SealFile?seal=2307&file=pdf
** EV: https://cert.webtrust.org/SealFile?seal=2279&file=pdf

I’ve reviewed the CPS, BR Self Assessment, and related information for the
Chunghwa Telecom eCA inclusion request that is being tracked in this bug
and have the following comments:

==Good==
* Clean WebTrust & BR audit statements cover periods back to the creation
of this root in 2015.
* The CPSs properly document 825 day maximum validity periods, and change
logs were recently added.

==Meh==
* Both of the domain validation methods that will be deprecated on 1-August
are currently listed as in-use in the root CP/CPS
* CAA Issuer Domain Names are only specified in the root CP, in section
1.3.2.2 rather than 2.2.
* For domain validation, each CPS does not state which subsection of BR
3.2.2.4 it is complying with as recommended by our policy.
* There is, in my opinion, an excessive amount of duplication of
information between the CP and 3 CPSs (over 600 pages in total), making the
review of these docs difficult and tedious.

==Bad==
* A large number of certificates have been misissued from the “Public
Certification Authority - G2” intermediate [4] (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

[lcchen...@gmail.com]

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

> I’ve reviewed the CPS, BR Self Assessment, and related information for the
> Chunghwa Telecom eCA inclusion request that is being tracked in this bug
> and have the following comments:
>
> ==Good==
> * Clean WebTrust & BR audit statements cover periods back to the creation
> of this root in 2015.
> * The CPSs properly document 825 day maximum validity periods, and change
> logs were recently added.
>
> ==Meh==
> * Both of the domain validation methods that will be deprecated on 1-August
> are currently listed as in-use in the root CP/CPS
> * CAA Issuer Domain Names are only specified in the root CP, in section
> 1.3.2.2 rather than 2.2.
> * For domain validation, each CPS does not state which subsection of BR
> 3.2.2.4 it is complying with as recommended by our policy.

> - Wayne
>

Dear Wayne,

I attached current ePKI CP V1.6 as https://bugzilla.mozilla.org/attachment.cgi?id=8982747.

ePKI Root CA (eCA) CPS version 1.5 as https://bugzilla.mozilla.org/attachment.cgi?id=8982748

ePKI EVSSL CA CPS version 1.2 as https://bugzilla.mozilla.org/attachment.cgi?id=8982749

PublicCA CPS Version 1.8 as https://bugzilla.mozilla.org/attachment.cgi?id=8982750

Both of the domain validation methods that will be deprecated on August 1 are not used now. Please see Section 3.2.5 of CPSs of two Sub-CAs. (ePKI EVSSL CA CPS version 1.2 and PublicCA CPS Version 1.8). For domain validation, Section 3.2.5 of these two CPSs state which subsection of BR 3.2.2.4 it is complying with as recommended by Mozilla Root Store Policy.

As for CP and 3 CPS about CAA issuer domain names.
Please see Section 1.3.2.2 and Section 4.2.1 of ePKI CP Version 1.6.
Please see Section 2.2 of ePKI Root CA(eCA) CPS version 1.5.
Please see Section 2.2 and Section 4.2.1.1 of ePKI EV SSL CA Version 1.2.
Please see Section 2.2 and Section 4.2.1 of PublicCA CPS Version 1.8.

Because our president of Data Communications Business Group, Chunghwa Telecom Co., Ltd. went abroad for three weeks. After he went back to Taiwan, he approved the reorganization of "Policy Management Committee" (See Section 1.3.1 of ePKI CP) on May 21. Policy Management Committee approved the amended CP and 3 CPSs on May 28. Thanks for your reviewing about CP and 3CPSs.

Sincerely Yours,

Li-chun

[lcchen...@gmail.com]

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 [4] (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

[lcchen...@gmail.com]

lcchen...@gmail.com於 2018年6月5日星期二 UTC+8下午5時22分40秒寫道：

>
> 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.

We mean that the new certificate format will contain an EKU that doesn’t include anyPolicy, emailProtection or serverAuth in it. Thanks.

Li-Chun

[lcchen...@gmail.com]

lcchen...@gmail.com於 2018年6月5日星期二 UTC+8下午6時25分00秒寫道：

Dear Wayne,

After furthermore investigating these 10 dedicated server application software certificates, we found that 5 of them are not in use now.

So these subscribers applied for revoking their certificates, and the RA officer of this certificate group revoked these 5 certificates in advance and we updated the file as attached.

As you can see in that file of https://bugzilla.mozilla.org/attachment.cgi?id=8984073, the Status column of these 5 certificates are marked as ‘revoked’ with the revocation time in the parentheses.

As for the rest 5 valid certificates, we will also revoke them once their new certificates with the new format is issued, as we planned before.

Sincerely Yours,

Li-Chun

[lcchen...@gmail.com]

Dear Wayne,

Our two customers requested to use original CSR to issue two shorter validity SSL certificates. By the re-issuance function of a program, to insert original applications data, our SSL RA Officers checked the addresses but they forgot to add L in Subject DN. So there are two SSL Certificates as below lack of L or S in Subject DN.

1.Serial Number:20BD5F0B51809E44C0718AB133CA5E78 CN=*.sercomm.com, O=中磊電子股份有限公司, C=TW or https://crt.sh/?id=508868868

2.Serial Number:3CE33A6D8899A211FB2D296D9E0B69CB CN=app3.uupon.tw, O=點鑽整合行銷股份有限公司, C=TW or https://crt.sh/?id=512788172

Our researchers of Telecommunication Laboratories of Chunghwa Telecom found above issue on June 11 and told our SSL RA Officers to contact the customers. When I was back to my office after the travlelling from England and disussed with my colleauges, I mailed the situation and the plan to Wayne and Kathleen on June 15.

This certificate of https://crt.sh/?id=512788172 was revoked on June 11 soon.

We have re-issued new certificates for two customers as below:

42664EEA106F2CBF736ADBF949D4218F CN=*.sercomm.com, O=中磊電子股份有限公司, L=臺北市, C=TW or https://crt.sh/?id=519100183

100079C87402938109A5FEC040C5BE0F CN=app3.uupon.tw, O=點鑽整合行銷股份有限公司, L=臺北市, C=TW or https://crt.sh/?id=549539943

After our customer installed a new certificate (https://crt.sh/?id=519100183) in their web servers, network equipments and firewall, The certificate of https://crt.sh/?id=508868868 was revoked on June 21,.

The checking function of Subject DN about either L or S are online June 22. I mailed to Wayne and Kathleen on June 22.

We confirm that the problem has been solved and will not happen in the future.

As we have discussed in CABF, Taiwan is a small country without state/provinces. We follow X.500, X.520 and Taiwan’s government’s DIT for the certificates. We can unique identify the subject without state/provinces and locality in DN for a central government agency or a company. (For example, In Taiwan's Company Act, https://law.moj.gov.tw/Eng/LawClass/LawAll.aspx?PCode=J0080001, Article 18 No company may use a corporate name which is identical with that of another company. ). We really receive some subscribers of central government agency or a company asked why your CA adds L in the subject DN of an SSL certificate. We explain that we follow the BR about either L or S should be in Subject DN now.

[lcchen...@gmail.com]

Dear Wayne,

The previous email has some typos, corrected as follows.

1. When I was back to my office after the travlelling from England and disussed with my colleauges, I mailed the situation and the plan to Wayne and Kathleen on June 15.

====> When I was back to my office after the travleling from England and discussed with my colleagues, I mailed the situation and the plan to Wayne and Kathleen on June 15.


2. After our customer installed a new certificate (https://crt.sh/?id=519100183) in their web servers, network equipments and firewall, The certificate of https://crt.sh/?id=508868868 was revoked on June 21.

====>

After our customer installed a new certificate (https://crt.sh/?id=519100183) in their web servers, network equipment and firewall, The certificate of https://crt.sh/?id=508868868 was revoked on June 21.

Sincerely Yours,

Li-Chun


lcchen...@gmail.com於 2018年7月7日星期六 UTC+8下午11時39分17秒寫道：

[lcchen...@gmail.com]

lcchen...@gmail.com於 2018年6月5日星期二 UTC+8下午5時22分40秒寫道：

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

[Wayne Thayer]

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 <
dev-secur...@lists.mozilla.org> wrote:

> lcchen...@gmail.com於 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]).

> 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
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

[lcchen...@gmail.com]

Dear Wayne,

Those programs for checking field of ToBeSign SSL certificate are online on June 22.

We suggest that CA "in principle" must comply with the string length limit of RFC 5280 for organizationalUnitName or organizationName filed in Subject of a certificate. But if it is necessary after verification to express an organization’s name in the organizationalUnitName or organizationName filed of the subject field that exceeds the string length limit of RFC 5280, then Mozilla should not regard these special cases as errors of a CA. After all, X.500 standard has no limit on the length of the string, and let the issuing CA and the Subscriber who has accepted that SSL certificate may bear the possibility of any incompatibility issues.

For the unrevoked certificate with length of organizationalUnitName more than 64 characters https://crt.sh/?id=336874396, Its Subject DN is as below

commonName = www.gov.vc
organizationalUnitName = Information Technology Services Division
organizationalUnitName = Ministry of Finance, Economic Planning, Sustainable Development and Information Technology
organizationName = Government of Saint Vincent and the Grenadines
countryName = VC

Because Saint Vincent and the Grenadines is a very, very small country with 120 thousand citizens. Many Ministries are consolidated, so the organizationalUnitName of the Ministry becomes longer. Why not let the Registration Authority Officers fill in the name of the certificate subject with the correct organization’s full name? Or should it be expressed in short abbreviations with ambiguous meaning?

There is no consensus on the length of the string in the CAB Forum Baseline Requirements, but in the case we have encountered, more than 64 characters for an organization name does exist.

Ben Wilson, Vice Chair of current CAB Forum, proposed to amend the Baseline Requirements to relax the length of the commonName and organizationName strings in April of 2017. Ben first posted his draft revision of BR amendment to PKIX's mailing list for comments. Because of the FQDN length in the commonName may be more than 64 characters, and the organization name in organizationName may exceed 64 characters.

Please read Https://www.ietf.org/mail-archive/web/pkix/current/msg33853.html

Ben's article was discussed in a series of PKIX mailing lists.

Erik Andersen, who is currently responsible for the revision of the X.500 series standards, mentioned that since the 2008 version of the X.520 standard, the string definition of these attributes has been changed from DirectoryString to UnboundedDirectoryString, and UnboundedDirectoryString is basically unlimited. That is to say, the length of the string, from the source of RFC 5280 : X.500 series is now not limited.

UnboundedDirectoryString ::= CHOICE {
teletexString TeletexString(SIZE (1..MAX)),
printableString PrintableString(SIZE (1..MAX)),
bmpString BMPString(SIZE (1..MAX)),
universalString UniversalString(SIZE (1..MAX)),
uTF8String UTF8String(SIZE (1..MAX)) }


The main reason of the X.500 series of standards removed the string length limit is to let the ISO/ITU-T Directory standard compatible with LDAP, because the LDAP standard does not limit the string length of the attribute.

However, when RFC 5280 was originally developed, the referenced X.500 standard version has a limit on the length of the attribute string. In the PKIX discussion thread, because the RFC 5280 standard has been cited by the industry for many years, some people are worried that if you go back to the RFC 5280 string length limit, or if the CA/Browser Forum jumps off the RFC 5280 string length limit, it is possible will cause compatibility problems, and finally this discussion string did not reach a conclusion.

Sincerely Yours,

Li-Chun




Wayne Thayer於 2018年7月11日星期三 UTC+8上午7時10分20秒寫道：

[Kurt Roeckx]

On 2018-07-13 12:02, lcchen...@gmail.com wrote:
> We suggest that CA "in principle" must comply with the string length limit of RFC 5280 for organizationalUnitName or organizationName filed in Subject of a certificate. But if it is necessary after verification to express an organization’s name in the organizationalUnitName or organizationName filed of the subject field that exceeds the string length limit of RFC 5280, then Mozilla should not regard these special cases as errors of a CA. After all, X.500 standard has no limit on the length of the string, and let the issuing CA and the Subscriber who has accepted that SSL certificate may bear the possibility of any incompatibility issues.

As pointed out in the discussion, RFC 5280 itself has those limits, and
references an older X.509 standard that also has the limits. RFC 5280 is
what is implemented. What documents like CA/B Forum requirements or
newer X.509 versions say is not relevant. The CA/B Forum can not remove
requirements, only add new requirements. Implementations can and do
implement the RFC 5280 / X.509 length limits.

If you want those lengths to be changed, an update of RFC 5280 is
required. And it seems unlikely that this will actually get changed.


Kurt

[Wayne Thayer]

On Fri, Jul 13, 2018 at 3:03 AM lcchen.cissp--- via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> Dear Wayne,
>
> Those programs for checking field of ToBeSign SSL certificate are
> online on June 22.
>

> We suggest that CA "in principle" must comply with the string length
> limit of RFC 5280 for organizationalUnitName or organizationName filed in
> Subject of a certificate. But if it is necessary after verification to
> express an organization’s name in the organizationalUnitName or
> organizationName filed of the subject field that exceeds the string length
> limit of RFC 5280, then Mozilla should not regard these special cases as
> errors of a CA. After all, X.500 standard has no limit on the length of the
> string, and let the issuing CA and the Subscriber who has accepted that SSL
> certificate may bear the possibility of any incompatibility issues.
>

> In effect, this is saying that CAs should be permitted to break
well-defined rules when they find them inconvenient. This is the second
example in which Chunghwa Telecom has argued that it's okay to do this
(along with the Taiwan State/Locality issue). While I can sympathize with
Chunghwa Telecom's reason for doing this, it is quite troubling because it
implies that Chunghwa Telecom may be willing to ignore any of the rules
they disagree with.

> I disagree that the discussion string referenced above did not reach a
conclusion. A number of interoperability concerns were raised, causing the
proposal to be rejected. By violating RFC 5280 in this manner, Chunghwa
Telecom has created an additional burden and risk for Mozilla by expecting
our software to accommodate non-standards-compliant certificates.

Sincerely Yours,
>
> Li-Chun
>

[Ryan Sleevi]

On Sat, Jul 14, 2018 at 2:16 AM Wayne Thayer via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

Further, considering where this overflow occurred, it was entirely
unnecessary and avoidable by the CA.

This speaks to gross negligence rather than considered risk.

[lcchen...@gmail.com]

Wayne Thayer於 2018年7月14日星期六 UTC+8上午1時16分58秒寫道：

> > In effect, this is saying that CAs should be permitted to break
> well-defined rules when they find them inconvenient. This is the second
> example in which Chunghwa Telecom has argued that it's okay to do this
> (along with the Taiwan State/Locality issue). While I can sympathize with
> Chunghwa Telecom's reason for doing this, it is quite troubling because it
> implies that Chunghwa Telecom may be willing to ignore any of the rules
> they disagree with.

> > I disagree that the discussion string referenced above did not reach a
> conclusion. A number of interoperability concerns were raised, causing the
> proposal to be rejected. By violating RFC 5280 in this manner, Chunghwa
> Telecom has created an additional burden and risk for Mozilla by expecting
> our software to accommodate non-standards-compliant certificates.

Dear Wayne,

We used automated tools (base on zlint, x509lint)to check all to be signed SSL certificates from June 22, 2018. So there will be no SSL certificates of those two issues in the future.

Our vetting person had checked the mainstream browsers such as Firefox before RA Officer approved the certificate Request of crt.sh ID 336874396. There are no issue for longer than 64 characters of OU in Firefox such as https://mail.gov.vc/. He just asked me to help to express his thought for discussion.


Sincerely Yours,

Li-Chun

[Wayne Thayer]

While I sincerely appreciate the efforts of Chunghwa Telecom to respond to
questions and to remediate some of the issues that were identified here,
this discussion ha made it clear that this request should be denied. There
is a significant degree of misissuance associated with this root, some of
the misissuance was intentional, and remediation did not occur until the
problems were called out. I will resolve the inclusion bug as WONTFIX.
Chunghwa Telecom is encouraged to create a new root that is free of these
issues and to apply for the inclusion of that new root in the Mozilla
program.

- Wayne

On Sat, Jul 14, 2018 at 5:26 AM lcchen.cissp--- via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> Wayne Thayer於 2018年7月14日星期六 UTC+8上午1時16分58秒寫道：

> > > In effect, this is saying that CAs should be permitted to break
> > well-defined rules when they find them inconvenient. This is the second
> > example in which Chunghwa Telecom has argued that it's okay to do this
> > (along with the Taiwan State/Locality issue). While I can sympathize with
> > Chunghwa Telecom's reason for doing this, it is quite troubling because
> it
> > implies that Chunghwa Telecom may be willing to ignore any of the rules
> > they disagree with.

> > > I disagree that the discussion string referenced above did not reach a
> > conclusion. A number of interoperability concerns were raised, causing
> the
> > proposal to be rejected. By violating RFC 5280 in this manner, Chunghwa
> > Telecom has created an additional burden and risk for Mozilla by
> expecting
> > our software to accommodate non-standards-compliant certificates.
>

> Dear Wayne,
>
> We used automated tools (base on zlint, x509lint)to check all to be
> signed SSL certificates from June 22, 2018. So there will be no SSL
> certificates of those two issues in the future.
>
> Our vetting person had checked the mainstream browsers such as Firefox
> before RA Officer approved the certificate Request of crt.sh ID 336874396.
> There are no issue for longer than 64 characters of OU in Firefox such as
> https://mail.gov.vc/. He just asked me to help to express his thought for
> discussion.
>
>