Re: GlobalSign: SSL Certificates with US country code and invalid State/Prov

2019-08-28 Thread Ryan Sleevi via dev-security-policy
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

2019-08-28 Thread Jeremy Rowley via dev-security-policy
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

2019-08-28 Thread Matthew Hardeman via dev-security-policy
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

2019-08-28 Thread Ryan Sleevi via dev-security-policy
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

2019-08-22 Thread Jeremy Rowley via dev-security-policy
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

2019-08-22 Thread Jeremy Rowley via dev-security-policy
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

2019-08-22 Thread Doug Beattie via dev-security-policy
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