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秒寫道： > 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
