Re: GlobalSign: SSL Certificates with US country code and invalid State/Prov
On Wed, Aug 28, 2019 at 12:36 PM Jeremy Rowley wrote: > I've always thought the reason OV/EV ballots haven't been proposed/passed > is combination of a lack of interest from the browsers and the fact that > governance reform seems to get in the way of everything else. I've for > proposed tons of things over the years that simply fail because I can't get > enough interest because they aren't shiny enough to capture attention. I > don't think CAs would actually oppose a clean up ballot - and Hurst's > proposal to require the BR OIDs for OV/DV wasn't opposed by all CAs. > Not all CAs and no true Scots, but it's true that when Microsoft attempted to require this via policy, there were significant enough concerns that led them to withdraw some of these elements. > A ballot standardizing on abbreviated states (for example) would probably > pass. I think any ballot requiring a standard format of cert profiles would > actually pass. And I think they are talking about standardizing a list of > allowed sources for verifying incorporation on the validation working > group. The CAB Forum just moves more slowly than it used to. We can speed > it up by simply proposing more ballots. There's nothing that requires long > waiting periods. I mean, I think we're more in agreement than disagreement. Browsers have higher priorities, generally focused on ensuring their existing members are compliant and actually following the rules set out by the contracts and root policy expectations, and that the issues that the CAs have are getting addressed meaningfully and in a timely fashion. I can assure you, it's a full time job and then some - between Kathleen handling the additions, Wayne doing CP/CPS reviews and supporting Mozilla, and myself doing many of the incident investigations, there's very little time for much else. CAs, as a collective (although there are of course individual exceptions), haven't really taken to improving things for relying parties. It may be that CAs don't understand the challenges RPs face, or it may be that they don't recognize the innate value in consistency. I've had conversations with CAs, about allowlists, and I've gotten enough pushback from enough CAs to say "OK, it's a better use of time to focus on the things of immediate concern - like SC22 - than to try and fight a battle on two fronts". We know some members of the CA/Browser Forum were so vociferously opposed to improved requirements of RAs that the amount of time it would take to improve things was simply not proportionate to the value browsers would receive; after all, it'd only apply to OV/EV, and as we see, if CAs are willing to let those go fallow, so be it. It's worth noting that GLEIF itself made it clear that they saw many of these issues and designed both the administrative structure and the requirements to learn from these mistakes. Conceptually, an LOU recognized by GLEIF is doing the same thing a CA recognized by a browser is doing for OV/EV - vetting organizational information. It's conceptually similar to eIDAS, in that there's multiple legal frameworks incorporating those results, but very distinct from eIDAS, in that it's independent and non-profit. Structurally, decisions are not made by the LOUs (aka CAs), they're made by the LEI ROC (aka Browsers) - those who depend on the stability and correctness of the system. GLEIF acts as a caretaker, but itself remains independent from the LOUs and the system itself. You can read more https://www.gleif.org/en/about/governance/mou-between-gleif-and-lei-roc# , but I highlight it to emphasize that, structurally, the answer for why hasn't much been done has been that the incentives are misaligned for CAs to do this, the value to browsers is commensurately low (e.g. why browsers don't recognize OV and have expressed concerns with EV, among other things). Anyways, that's my pitch for why 1) Folks should file Moz Policy issues first and foremost, because that's a direct way you have to raise and highlight concerns 2) Care needs to be taken to "do it right" - this is true of all standards work, and doesn't come overnight, but it can start by just making sure there's a clear description of the problem and a clear description of the considerations made 3) Either Mozilla may bring these issues to the Forum (if they are priorities for Mozilla), or CAs may want to consider doing so (if it impacts the value proposition to Relying Parties) Nothing prevents change, except for the number of hours in a day :) ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: GlobalSign: SSL Certificates with US country code and invalid State/Prov
I've always thought the reason OV/EV ballots haven't been proposed/passed is combination of a lack of interest from the browsers and the fact that governance reform seems to get in the way of everything else. I've for proposed tons of things over the years that simply fail because I can't get enough interest because they aren't shiny enough to capture attention. I don't think CAs would actually oppose a clean up ballot - and Hurst's proposal to require the BR OIDs for OV/DV wasn't opposed by all CAs. A ballot standardizing on abbreviated states (for example) would probably pass. I think any ballot requiring a standard format of cert profiles would actually pass. And I think they are talking about standardizing a list of allowed sources for verifying incorporation on the validation working group. The CAB Forum just moves more slowly than it used to. We can speed it up by simply proposing more ballots. There's nothing that requires long waiting periods. Heck, if interested parties want to work on ballots with me, I'd be happy to propose them at the CAB Forum. That'd be really fun actually - propose a bunch of relying party ballots from the Mozilla community that we put forward/sponsor. LMK -Original Message- From: dev-security-policy On Behalf Of Ryan Sleevi via dev-security-policy Sent: Wednesday, August 28, 2019 9:02 AM To: Corey Bonnell Cc: mozilla-dev-security-policy Subject: Re: GlobalSign: SSL Certificates with US country code and invalid State/Prov On Wed, Aug 28, 2019 at 7:13 AM Corey Bonnell via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > 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. > There's a long list of things that CAs that advocate for OV/EV information could be doing to make it reliable and useful to Relying Parties. Consider this post, from Ryan Hurst in 2012 - https://unmitigatedrisk.com/?p=203 - talking about the 'simple' challenges just in distinguishing DV vs OV certificates. The proliferation of CA-specific policy OIDs has, functionally, made this a non-trivial task. While the Baseline Requirements provide a series of policy OIDs that CAs may assert, the use is not mandatory nor widespread. With respect to OV/EV information, it's clear that in the absence of an allowlist, and more explicit profiles, the functional value to Relying Parties is going to be greatly limited. This is not an exclusive criticism of OV/EV either; the lack of technical profiles for both CRLs and OCSP represent significant challenges. The problem, as with all things in the Forum, is that the incentive structures are misaligned. There is questionable benefit, to a CA, to develop a ballot to normatively specify a requirement on the information sources or the formatting of certificates. While some have suggested the costs in determining adequate information sources (e.g. "does X meet the criteria of the BRs?") might be reduced by such a shared list, most of that cost has already been sunk by the extant CAs, so it only benefits new upstarts or those entering new jurisdictions. With profiles for certificates, it's even more marked - every profile represents a chance for the CA to be accused of violating them, and represents additional controls all CAs would need to implement. It's naturally in their own self-interest to not only not propose such changes, but oppose them when proposed, because it's all risk for benefit that they and their Subscribers do not realize. So it's left to browsers to normatively require things, much as it was with the Baseline Requirements. And we know the browsers are a busy lot, in part due to the influx of issues and the woeful responses and/or remediations. So what can be done? If folks joined the CA/Browser Forum as Interested Parties (and thus executed the IP agreement), it's a much quicker path towards writing technical changes which browsers might then be able to propose as draft ballots to then place into the BRs. Alternatively, folks here could open issues with Mozilla Policy, wholly ignoring the CA/Browser due to its many issues, proposing changes to Mozilla Policy. Mozilla could eventually propose the
Re: GlobalSign: SSL Certificates with US country code and invalid State/Prov
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 < dev-security-policy@lists.mozilla.org> 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 > on behalf of Corey Bonnell via dev-security-policy < > dev-security-policy@lists.mozilla.org> > > Sent: Thursday, August 22, 2019 8:57:42 PM > > To: Doug Beattie ; > mozilla-dev-security-pol...@lists.mozilla.org < > mozilla-dev-security-pol...@lists.mozilla.org> > > 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 > on behalf of Doug Beattie via dev-security-policy < > dev-security-policy@lists.mozilla.org> > > Sent: Thursday, August 22, 2019 11:35 > > To: mozilla-dev-security-pol...@lists.mozilla.org > > 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%7C84df9e7fe9f640afb435%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%7C84df9e7fe9f640afb435%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%7C84df9e7fe9f640afb435%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 i
Re: GlobalSign: SSL Certificates with US country code and invalid State/Prov
On Wed, Aug 28, 2019 at 7:13 AM Corey Bonnell via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > 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. > There's a long list of things that CAs that advocate for OV/EV information could be doing to make it reliable and useful to Relying Parties. Consider this post, from Ryan Hurst in 2012 - https://unmitigatedrisk.com/?p=203 - talking about the 'simple' challenges just in distinguishing DV vs OV certificates. The proliferation of CA-specific policy OIDs has, functionally, made this a non-trivial task. While the Baseline Requirements provide a series of policy OIDs that CAs may assert, the use is not mandatory nor widespread. With respect to OV/EV information, it's clear that in the absence of an allowlist, and more explicit profiles, the functional value to Relying Parties is going to be greatly limited. This is not an exclusive criticism of OV/EV either; the lack of technical profiles for both CRLs and OCSP represent significant challenges. The problem, as with all things in the Forum, is that the incentive structures are misaligned. There is questionable benefit, to a CA, to develop a ballot to normatively specify a requirement on the information sources or the formatting of certificates. While some have suggested the costs in determining adequate information sources (e.g. "does X meet the criteria of the BRs?") might be reduced by such a shared list, most of that cost has already been sunk by the extant CAs, so it only benefits new upstarts or those entering new jurisdictions. With profiles for certificates, it's even more marked - every profile represents a chance for the CA to be accused of violating them, and represents additional controls all CAs would need to implement. It's naturally in their own self-interest to not only not propose such changes, but oppose them when proposed, because it's all risk for benefit that they and their Subscribers do not realize. So it's left to browsers to normatively require things, much as it was with the Baseline Requirements. And we know the browsers are a busy lot, in part due to the influx of issues and the woeful responses and/or remediations. So what can be done? If folks joined the CA/Browser Forum as Interested Parties (and thus executed the IP agreement), it's a much quicker path towards writing technical changes which browsers might then be able to propose as draft ballots to then place into the BRs. Alternatively, folks here could open issues with Mozilla Policy, wholly ignoring the CA/Browser due to its many issues, proposing changes to Mozilla Policy. Mozilla could eventually propose these as ballots or, more pragmatically, CAs who have to follow these rules anyways might be inclined to formalize them into the BRs, rather than run the risk of future Root Store divergence. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: GlobalSign: SSL Certificates with US country code and invalid State/Prov
I only know because I was looking at this issue tonight as well to add an update later to the joi bug I posted. From: dev-security-policy on behalf of Jeremy Rowley via dev-security-policy Sent: Thursday, August 22, 2019 9:07:51 PM To: Corey Bonnell ; Doug Beattie ; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: GlobalSign: SSL Certificates with US country code and invalid State/Prov 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 on behalf of Corey Bonnell via dev-security-policy Sent: Thursday, August 22, 2019 8:57:42 PM To: Doug Beattie ; mozilla-dev-security-pol...@lists.mozilla.org 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 on behalf of Doug Beattie via dev-security-policy Sent: Thursday, August 22, 2019 11:35 To: mozilla-dev-security-pol...@lists.mozilla.org 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%7C84df9e7fe9f640afb435%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%7C84df9e7fe9f640afb435%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%7C84df9e7fe9f640afb435%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 dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: GlobalSign: SSL Certificates with US country code and invalid State/Prov
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 on behalf of Corey Bonnell via dev-security-policy Sent: Thursday, August 22, 2019 8:57:42 PM To: Doug Beattie ; mozilla-dev-security-pol...@lists.mozilla.org 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 on behalf of Doug Beattie via dev-security-policy Sent: Thursday, August 22, 2019 11:35 To: mozilla-dev-security-pol...@lists.mozilla.org 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%7C84df9e7fe9f640afb435%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%7C84df9e7fe9f640afb435%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%7C84df9e7fe9f640afb435%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 dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
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://bugzilla.mozilla.org/show_bug.cgi?id=1575880 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://crt.sh/?id=1285639832 https://crt.sh/?id=413247173 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. smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
