Re: Chunghwa Telecom eCA Root Inclusion Request
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-security-policy@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. > > > Sincerely Yours, > > Li-Chun > > ___ > 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
Re: Chunghwa Telecom eCA Root Inclusion Request
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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Chunghwa Telecom eCA Root Inclusion Request
On Sat, Jul 14, 2018 at 2:16 AM Wayne Thayer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Fri, Jul 13, 2018 at 3:03 AM lcchen.cissp--- via dev-security-policy <
> dev-security-policy@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.
>
>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 {
> > teletexStringTeletexString(SIZE (1..MAX)),
> > printableString PrintableString(SIZE (1..MAX)),
> > bmpStringBMPString(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.
> >
> > I disagree that the discussion string referenced above did not rea
Re: Chunghwa Telecom eCA Root Inclusion Request
On Fri, Jul 13, 2018 at 3:03 AM lcchen.cissp--- via dev-security-policy <
dev-security-policy@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.
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 {
> teletexStringTeletexString(SIZE (1..MAX)),
> printableString PrintableString(SIZE (1..MAX)),
> bmpStringBMPString(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.
>
> 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,
>
>
Re: Chunghwa Telecom eCA Root Inclusion Request
On 2018-07-13 12:02, lcchen.ci...@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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Chunghwa Telecom eCA Root Inclusion Request
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 {
teletexStringTeletexString(SIZE (1..MAX)),
printableString PrintableString(SIZE (1..MAX)),
bmpStringBMPString(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秒寫道：
> 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
Re: Chunghwa Telecom eCA Root Inclusion Request
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-security-policy@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]). > 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=898. > > > >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
Re: Chunghwa Telecom eCA Root Inclusion Request
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 [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=898. > >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 dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Chunghwa Telecom eCA Root Inclusion Request
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秒寫道： > 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. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Chunghwa Telecom eCA Root Inclusion Request
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. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Chunghwa Telecom eCA Root Inclusion Request
lcchen...@gmail.com於 2018年6月5日星期二 UTC+8下午6時25分00秒寫道： > 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 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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Chunghwa Telecom eCA Root Inclusion Request
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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Chunghwa Telecom eCA Root Inclusion Request
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=898. 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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Chunghwa Telecom eCA Root Inclusion Request
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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Chunghwa Telecom eCA Root Inclusion Request
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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
