I'd particularly like to see the memes directly within the certificate, maybe an extension to RFC 6170.
On Wed, Aug 28, 2019 at 6:13 AM Corey Bonnell via dev-security-policy < [email protected]> wrote: > On Thursday, August 22, 2019 at 11:08:03 PM UTC-4, Jeremy Rowley wrote: > > It's a trap. I do wish memes showed up here.... > > > > Censys shows something like 130 globalsign certs with abbreviated joi > info. I think we show 16? > > ________________________________ > > From: dev-security-policy <[email protected]> > on behalf of Corey Bonnell via dev-security-policy < > [email protected]> > > Sent: Thursday, August 22, 2019 8:57:42 PM > > To: Doug Beattie <[email protected]>; > [email protected] < > [email protected]> > > Subject: Re: GlobalSign: SSL Certificates with US country code and > invalid State/Prov > > > > Hi Doug, > > Thank for you for posting this incident report to the list. I have one > clarifying question in regard to the correctness criteria for the jurisST > field when performing the scanning for additional problematic certificates. > Is GlobalSign allowing state abbreviations in the jurisST field, or only > full state names? > > Thanks, > > Corey > > > > ________________________________ > > From: dev-security-policy <[email protected]> > on behalf of Doug Beattie via dev-security-policy < > [email protected]> > > Sent: Thursday, August 22, 2019 11:35 > > To: [email protected] > > Subject: GlobalSign: SSL Certificates with US country code and invalid > State/Prov > > > > Today we opened a bug disclosing misissuance of some certificates that > have > > invalid State/Prov values: > > > > > https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.mozilla.org%2Fshow_bug.cgi%3Fid%3D1575880&data=02%7C01%7C%7Ceba31d5add5949261f1508d7271662df%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637020849406465940&sdata=sgDFjHsrYMjJMl02%2Bj3BH7Hw%2FUPNR3O8q6r8nr3OgZE%3D&reserved=0 > > > > > > > > On Tuesday August 20th 2019, GlobalSign was notified by a third party > > through the report abuse email address that two certificates were > discovered > > which contained wrong State information, either in the > stateOrProvinceName > > field or in the jurisdictionStateOrProvinceName field. > > > > > > > > The two certificates in question were: > > > > > https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcrt.sh%2F%3Fid%3D1285639832&data=02%7C01%7C%7Ceba31d5add5949261f1508d7271662df%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637020849406465940&sdata=jXC4T%2BbvYYNdPJhXUukJT7cGEYgv0Lyg3qFO81S9xPE%3D&reserved=0 > > > > > https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcrt.sh%2F%3Fid%3D413247173&data=02%7C01%7C%7Ceba31d5add5949261f1508d7271662df%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637020849406465940&sdata=KJ7FfggP5XKliFv%2FL2VLwpRtG8bcg7Eq%2FzFG6qx8ndQ%3D&reserved=0 > > > > > > > > GlobalSign started and concluded the investigation within 24 hours. > Within > > this timeframe GlobalSign reached out to the Certificate owners that > these > > certificates needed to be replaced because revocation would need to > happen > > within 5 days, following the Baseline Requirements. As of the moment of > > reporting, these certificates have not yet been replaced, and the > offending > > certificates have not been revoked. The revocation will happen at the > latest > > on the 25th of August. > > > > > > > > Following this report, GlobalSign initiated an additional internal review > > for this problem specifically (unexpected values for US states in values > in > > the stateOrProvinceName or jurisdictionStateOrProvinceName fields). > Expected > > values included the full name of the States, or their official > abbreviation. > > We reviewed all certificates, valid on or after the 21st of August, that > > weren't revoked for other unrelated reasons. > > > > > > > > To accommodate our customers globally, the stateOrProvinceName field or > in > > the jurisdictionStateOrProvinceName are text fields during our ordering > > process. The unexpected values were not spotted or not properly > corrected. > > We have put additional flagging in place to highlight unexpected values > in > > both of these fields, and are looking at other remedial actions. None of > > these certificates were previously flagged for internal audit, which is > > completely randomized. > > > > > > > > We will update with a full incident report for this and also disclose all > > other certificates found based on our research. > > > > _______________________________________________ > > dev-security-policy mailing list > > [email protected] > > https://lists.mozilla.org/listinfo/dev-security-policy > > At the risk of turning this place into Reddit, I agree that a meme feature > is needed. > > Anyhow, judging from censys.io, it looks like there are far bigger > offenders of this particular quirky rule than Digicert and GlobalSign. I'd > love to know why the BRs/EVGs are inconsistent with this requirement for > jurisST having to be a full name, but ST can seemingly be either. It looks > like the existing language in the BRs for ST stemmed from Ballot 88, but > unfortunately there was little discussion on the mailing list that I could > find about the rationale for this inconsistency. > > Ideally, the requirements would be identical so that Relying Parties can > more easily extract identity information from these certificates to aid in > trust decisions. > > Thanks, > Corey > _______________________________________________ > 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
