RE: Do We Now Require Separate Cross-certificates for SSL and S/MIME?
Yeah, I agree I don’t think it was intended. But now that I am aware of the issue, I think the crossing workaround per EKU is actually a good thing for people to be doing. Unless someone can point out why it's bad ... Might want to give people a little more time to plan and adapt to that change though since I doubt anyone thought of it and people need planning runway to change their procedures if it is going to be interpreted this way. -Tim > -Original Message- > From: dev-security-policy [mailto:dev-security-policy- > bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of Bruce via > dev-security-policy > Sent: Friday, July 13, 2018 10:17 AM > To: mozilla-dev-security-pol...@lists.mozilla.org > Subject: Re: Do We Now Require Separate Cross-certificates for SSL and > S/MIME? > > Agreed that old cross-certificates will not be impacted, but this does impact > new cross-certificates. I assume the work around would be to just issue more > than one cross-certificate with different EKUs, but I don't assume that was > intended by this policy change. > > Bruce. > > On Friday, July 13, 2018 at 8:02:00 AM UTC-4, Tim Hollebeek wrote: > > Doesn't the "created after January 1, 2019" mean that there is no problem > with old crosses? It would just be a new policy for new crosses as of next > year? > > > > -Tim > > > > > -Original Message- > > > From: dev-security-policy [mailto:dev-security-policy- > > > bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of > > > bounces+Bruce via > > > dev-security-policy > > > Sent: Thursday, July 12, 2018 10:28 AM > > > To: mozilla-dev-security-pol...@lists.mozilla.org > > > Subject: Re: Do We Now Require Separate Cross-certificates for SSL > > > and S/MIME? > > > > > > Note the BRs define Cross Certificate as "a certificate that is used > > > to establish a trust relationship between two Root CAs." > > > > > > I think the intent was to technically restrict subordinate CAs or > > > rather CAs which are online and issue end entity certificates. My > > > assumption is that we want to 1) not allow a subordinate CA to issue > > > a certificate which it was no intended to issue and 2) mitigate the > > > risk if an online subordinate CA has been compromised. > > > > > > Typically, if an old root cross-certifies a new root, the purpose is > > > to give the new root browser/OS ubiquity. The new root may be used > > > to support end entity certificates of many types (e.g., Server Auth, > > > S/MIME, Client Auth, Code Signing, Document Signing, Time-stamping > > > ...). If we restrict the cross- certificate, then this will limit > > > the use of a new root. Also note that the new root is 1) not an > > > issuing CA and 2) is offline, so the mitigation of technical restriction > > > may > already be satisfied. > > > > > > Thanks, Bruce. > > > > > > On Tuesday, July 10, 2018 at 7:21:26 PM UTC-4, Wayne Thayer wrote: > > > > During a 2.6 policy discussion [1], we agreed to add the following > > > > language to section 5.3 "Intermediate Certificates": > > > > > > > > > Intermediate certificates created after January 1, 2019: > > > > > > > > > > > > > > > * MUST contain an EKU extension; and, > > > > > * MUST NOT include the anyExtendedKeyUsage KeyPurposeId; and, > > > > > * MUST NOT include both the id-kp-serverAuth and > > > > > id-kp-emailProtection KeyPurposeIds in the same certificate. > > > > > > > > > > > > > It has been pointed out to me that the very next paragraph of > > > > section > > > > 5.3 > > > > states: > > > > > > > > These requirements include all cross-certified certificates which > > > > chain to > > > > > a certificate that is included in Mozilla’s CA Certificate Program. > > > > > > > > > > > > > The term "cross-certified certificates" could refer to the actual > > > > cross-certificate, or it could refer to intermediate certificates > > > > that chain up to the cross certificate. In the case of a root that > > > > is being cross-certified, the former interpretation effectively > > > > means that distinct cross-certificates would be required for > > > > serverAuth and emailProtection, as > > > > follows: > > > > > > > > 1 - Root <-- Cross-certificate (EKU=emailProtection) <-- > > > > Intermediate certificate (EKU=emailProtection) <-- leaf > > > > certificate (S/MIME) > > > > 2 - Root <-- Cross-certificate (EKU=serverAuth) <-- Intermediate > > > > certificate (EKU=serverAuth) <-- leaf certificate (SSL/TLS) > > > > > > > > Should our policy require cross-certificates to be constrained to > > > > either serverAuth or emailProtection via EKU, or should this > > > > requirement only apply to [all other] intermediate certificates? > > > > > > > > What is the correct interpretation of section 5.3 of the policy as > > > > currently written? > > > > > > > > I would appreciate everyone's input on these questions. > > > > > > > > - Wayne > > > > > > > > [1] > > > > > > > >
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
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: Do We Now Require Separate Cross-certificates for SSL and S/MIME?
Agreed that old cross-certificates will not be impacted, but this does impact new cross-certificates. I assume the work around would be to just issue more than one cross-certificate with different EKUs, but I don't assume that was intended by this policy change. Bruce. On Friday, July 13, 2018 at 8:02:00 AM UTC-4, Tim Hollebeek wrote: > Doesn't the "created after January 1, 2019" mean that there is no problem > with old crosses? It would just be a new policy for new crosses as of next > year? > > -Tim > > > -Original Message- > > From: dev-security-policy [mailto:dev-security-policy- > > bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of Bruce via > > dev-security-policy > > Sent: Thursday, July 12, 2018 10:28 AM > > To: mozilla-dev-security-pol...@lists.mozilla.org > > Subject: Re: Do We Now Require Separate Cross-certificates for SSL and > > S/MIME? > > > > Note the BRs define Cross Certificate as "a certificate that is used to > > establish a > > trust relationship between two Root CAs." > > > > I think the intent was to technically restrict subordinate CAs or rather CAs > > which are online and issue end entity certificates. My assumption is that we > > want to 1) not allow a subordinate CA to issue a certificate which it was no > > intended to issue and 2) mitigate the risk if an online subordinate CA has > > been > > compromised. > > > > Typically, if an old root cross-certifies a new root, the purpose is to > > give the > > new root browser/OS ubiquity. The new root may be used to support end > > entity certificates of many types (e.g., Server Auth, S/MIME, Client Auth, > > Code > > Signing, Document Signing, Time-stamping ...). If we restrict the cross- > > certificate, then this will limit the use of a new root. Also note that the > > new > > root is 1) not an issuing CA and 2) is offline, so the mitigation of > > technical > > restriction may already be satisfied. > > > > Thanks, Bruce. > > > > On Tuesday, July 10, 2018 at 7:21:26 PM UTC-4, Wayne Thayer wrote: > > > During a 2.6 policy discussion [1], we agreed to add the following > > > language to section 5.3 "Intermediate Certificates": > > > > > > > Intermediate certificates created after January 1, 2019: > > > > > > > > > > > > * MUST contain an EKU extension; and, > > > > * MUST NOT include the anyExtendedKeyUsage KeyPurposeId; and, > > > > * MUST NOT include both the id-kp-serverAuth and > > > > id-kp-emailProtection KeyPurposeIds in the same certificate. > > > > > > > > > > It has been pointed out to me that the very next paragraph of section > > > 5.3 > > > states: > > > > > > These requirements include all cross-certified certificates which > > > chain to > > > > a certificate that is included in Mozilla’s CA Certificate Program. > > > > > > > > > > The term "cross-certified certificates" could refer to the actual > > > cross-certificate, or it could refer to intermediate certificates that > > > chain up to the cross certificate. In the case of a root that is being > > > cross-certified, the former interpretation effectively means that > > > distinct cross-certificates would be required for serverAuth and > > > emailProtection, as > > > follows: > > > > > > 1 - Root <-- Cross-certificate (EKU=emailProtection) <-- Intermediate > > > certificate (EKU=emailProtection) <-- leaf certificate (S/MIME) > > > 2 - Root <-- Cross-certificate (EKU=serverAuth) <-- Intermediate > > > certificate (EKU=serverAuth) <-- leaf certificate (SSL/TLS) > > > > > > Should our policy require cross-certificates to be constrained to > > > either serverAuth or emailProtection via EKU, or should this > > > requirement only apply to [all other] intermediate certificates? > > > > > > What is the correct interpretation of section 5.3 of the policy as > > > currently written? > > > > > > I would appreciate everyone's input on these questions. > > > > > > - Wayne > > > > > > [1] > > > > > https://clicktime.symantec.com/a/1/82jRdde1a_TDsUNagUMK3MwXRBX4JdeH > > iAL > > > jfsD2zgM=?d=5n7PC5UMMMf8ow60aA_zACOHRkVy- > > 9DLApGl29o_1WR_vWTXMDk0d9kBFu > > > > > rU6JcvMPF1WEp4WBRfAgKXpN15C1244hstaDLxsVmE8bwd8UMj0MNvk5w_Q > > C8ibEWzPC_L > > > UljJwJbyQ12v- > > eTKN6FpHJwudbiXqkteAL6SsQfa0QGrVhJI2REzKkz7jXD0KovgoCzWAR > > > mueHAHVd9wo- > > Zf8cGao91RrkdklVah1kaEBTyUKOPMlGbnavPLTjmV4ZRDrnrDCFX4rkD1 > > > Lo77olEchKsy8cAbTYPtzG0lkCI1j4UDxcZ-FUsyVeArS- > > GdV0BnikfsrccHi35Z67abn6 > > > -KrVJCFHHsHbG6kEl9IjbK_HVe2tyNOP4Fkxpq2kv_Dws_N9PMOE- > > HQoRmqNABl-nFDxHu > > > Oru- > > 2ncWO24MRiohMbTk2xrGlehqHvYR2QII6nyw79ouwqK9GVtOi8GsmBewEssvkv > > Y6H_ > > > > > W_xOw3VB6Mp7gtxMSK0v72SLI%3D=https%3A%2F%2Fgroups.google.com > > %2Fd%2Fm > > > sg%2Fmozilla.dev.security.policy%2FQIweY3cHRyA%2FvbtnfJ4zCAAJ > > > > ___ > > dev-security-policy mailing list > > dev-security-policy@lists.mozilla.org > > https://clicktime.symantec.com/a/1/UqWB6X0ty8ImZMghiLXK4dj9WfPgHxf31p > >
RE: Do We Now Require Separate Cross-certificates for SSL and S/MIME?
Doesn't the "created after January 1, 2019" mean that there is no problem with old crosses? It would just be a new policy for new crosses as of next year? -Tim > -Original Message- > From: dev-security-policy [mailto:dev-security-policy- > bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of Bruce via > dev-security-policy > Sent: Thursday, July 12, 2018 10:28 AM > To: mozilla-dev-security-pol...@lists.mozilla.org > Subject: Re: Do We Now Require Separate Cross-certificates for SSL and > S/MIME? > > Note the BRs define Cross Certificate as "a certificate that is used to > establish a > trust relationship between two Root CAs." > > I think the intent was to technically restrict subordinate CAs or rather CAs > which are online and issue end entity certificates. My assumption is that we > want to 1) not allow a subordinate CA to issue a certificate which it was no > intended to issue and 2) mitigate the risk if an online subordinate CA has > been > compromised. > > Typically, if an old root cross-certifies a new root, the purpose is to give > the > new root browser/OS ubiquity. The new root may be used to support end > entity certificates of many types (e.g., Server Auth, S/MIME, Client Auth, > Code > Signing, Document Signing, Time-stamping ...). If we restrict the cross- > certificate, then this will limit the use of a new root. Also note that the > new > root is 1) not an issuing CA and 2) is offline, so the mitigation of technical > restriction may already be satisfied. > > Thanks, Bruce. > > On Tuesday, July 10, 2018 at 7:21:26 PM UTC-4, Wayne Thayer wrote: > > During a 2.6 policy discussion [1], we agreed to add the following > > language to section 5.3 "Intermediate Certificates": > > > > > Intermediate certificates created after January 1, 2019: > > > > > > > > > * MUST contain an EKU extension; and, > > > * MUST NOT include the anyExtendedKeyUsage KeyPurposeId; and, > > > * MUST NOT include both the id-kp-serverAuth and > > > id-kp-emailProtection KeyPurposeIds in the same certificate. > > > > > > > It has been pointed out to me that the very next paragraph of section > > 5.3 > > states: > > > > These requirements include all cross-certified certificates which > > chain to > > > a certificate that is included in Mozilla’s CA Certificate Program. > > > > > > > The term "cross-certified certificates" could refer to the actual > > cross-certificate, or it could refer to intermediate certificates that > > chain up to the cross certificate. In the case of a root that is being > > cross-certified, the former interpretation effectively means that > > distinct cross-certificates would be required for serverAuth and > > emailProtection, as > > follows: > > > > 1 - Root <-- Cross-certificate (EKU=emailProtection) <-- Intermediate > > certificate (EKU=emailProtection) <-- leaf certificate (S/MIME) > > 2 - Root <-- Cross-certificate (EKU=serverAuth) <-- Intermediate > > certificate (EKU=serverAuth) <-- leaf certificate (SSL/TLS) > > > > Should our policy require cross-certificates to be constrained to > > either serverAuth or emailProtection via EKU, or should this > > requirement only apply to [all other] intermediate certificates? > > > > What is the correct interpretation of section 5.3 of the policy as > > currently written? > > > > I would appreciate everyone's input on these questions. > > > > - Wayne > > > > [1] > > > https://clicktime.symantec.com/a/1/82jRdde1a_TDsUNagUMK3MwXRBX4JdeH > iAL > > jfsD2zgM=?d=5n7PC5UMMMf8ow60aA_zACOHRkVy- > 9DLApGl29o_1WR_vWTXMDk0d9kBFu > > > rU6JcvMPF1WEp4WBRfAgKXpN15C1244hstaDLxsVmE8bwd8UMj0MNvk5w_Q > C8ibEWzPC_L > > UljJwJbyQ12v- > eTKN6FpHJwudbiXqkteAL6SsQfa0QGrVhJI2REzKkz7jXD0KovgoCzWAR > > mueHAHVd9wo- > Zf8cGao91RrkdklVah1kaEBTyUKOPMlGbnavPLTjmV4ZRDrnrDCFX4rkD1 > > Lo77olEchKsy8cAbTYPtzG0lkCI1j4UDxcZ-FUsyVeArS- > GdV0BnikfsrccHi35Z67abn6 > > -KrVJCFHHsHbG6kEl9IjbK_HVe2tyNOP4Fkxpq2kv_Dws_N9PMOE- > HQoRmqNABl-nFDxHu > > Oru- > 2ncWO24MRiohMbTk2xrGlehqHvYR2QII6nyw79ouwqK9GVtOi8GsmBewEssvkv > Y6H_ > > > W_xOw3VB6Mp7gtxMSK0v72SLI%3D=https%3A%2F%2Fgroups.google.com > %2Fd%2Fm > > sg%2Fmozilla.dev.security.policy%2FQIweY3cHRyA%2FvbtnfJ4zCAAJ > > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://clicktime.symantec.com/a/1/UqWB6X0ty8ImZMghiLXK4dj9WfPgHxf31p > FYXlE5W5k=?d=5n7PC5UMMMf8ow60aA_zACOHRkVy- > 9DLApGl29o_1WR_vWTXMDk0d9kBFurU6JcvMPF1WEp4WBRfAgKXpN15C1244 > hstaDLxsVmE8bwd8UMj0MNvk5w_QC8ibEWzPC_LUljJwJbyQ12v- > eTKN6FpHJwudbiXqkteAL6SsQfa0QGrVhJI2REzKkz7jXD0KovgoCzWARmueHAH > Vd9wo- > Zf8cGao91RrkdklVah1kaEBTyUKOPMlGbnavPLTjmV4ZRDrnrDCFX4rkD1Lo77olE > chKsy8cAbTYPtzG0lkCI1j4UDxcZ-FUsyVeArS-GdV0BnikfsrccHi35Z67abn6- > KrVJCFHHsHbG6kEl9IjbK_HVe2tyNOP4Fkxpq2kv_Dws_N9PMOE-HQoRmqNABl- > nFDxHuOru- > 2ncWO24MRiohMbTk2xrGlehqHvYR2QII6nyw79ouwqK9GVtOi8GsmBewEssvkv > Y6H_W_xOw3VB6Mp7gtxMSK0v72SLI%3D=https%3A%2F%2Flists.mozilla.or >
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
