On Sat, Jul 14, 2018 at 2:16 AM Wayne Thayer via dev-security-policy < [email protected]> wrote:
> 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. > Further, considering where this overflow occurred, it was entirely unnecessary and avoidable by the CA. This speaks to gross negligence rather than considered risk. > 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
