On Fri, Jul 13, 2018 at 3:03 AM lcchen.cissp--- via dev-security-policy < [email protected]> 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 { > 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. > > 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 > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
