Re: Public Discussion of GlobalSign's CA Inclusion Request for R46, E46, R45 and E45 Roots

[Nick Lamb via dev-security-policy]

On Thu, 11 Feb 2021 15:12:46 -0500
Ryan Sleevi via dev-security-policy
 wrote:

> So I'd say feel free to ask your question there, which helps make
> sure it's answered before the issue is closed.

Good point. In this case Arvid has clarified that in fact the ticket
now has an updated sheet which (I haven't examined it yet) should
satisfy my question so I shan't follow up there except in the event I
have further questions.


> This is one of many outstanding items still
> for the Validation Working Group of the CA/B Forum, as possible
> mitigations were also discussed. In short, "capability URLs" (where
> the entire URL is, in effect, the capability) are dangerous.

Good to know.
 
> Note that there have been far more than "Ten Blessed Methods" since
> those discussions, so perhaps it's clearer to just say 3.2.2.4.

Personally I just like the way "Ten Blessed Methods" sounds.

I wouldn't reliably recognise all Thirty Six Views of Mount Fuji,
everything except (what I'd call) Big Wave, and Watermill could be any
of dozens of imitators as far as this uneducated eye is concerned - and
of course there are actually ten more of them, but we still call it
"Thirty Six Views of Mount Fuji".

The addition (and deprecation) of methods is an expected and desirable
course for the Baseline Requirements, and I am watching even if I don't
comment on it.

However because everything is formatted according to RFC 3647 (which is
a good thing), section 3.2.2.4 doesn't carry the same implication as
"Ten Blessed Methods". BR 1.3.0 had a section 3.2.2.4 it's just that it
doesn't in fact set down which methods must be used, which is how we
got here in the first place.

But I'm not old enough just yet to be incapable of learning new tricks,
I've learned to call it a "blocklist" not a "blacklist" and I'm sure if
everybody really starts to refer only to "3.2.2.4" I'll get used to
that.

Nick.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Public Discussion of GlobalSign's CA Inclusion Request for R46, E46, R45 and E45 Roots

[Ben Wilson via dev-security-policy]

All,
On Monday, I'm going to recommend to Kathleen that we proceed with these
root inclusion requests of GlobalSign.
Please let us know if there are any concerns.
Thanks,
Ben

On Fri, Feb 12, 2021 at 7:31 AM Arvid Vermote via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hi Nick
>
> We attached an updated version of the affected certificate overview to the
> bug on February 10, which does contain the date of order and date of
> issuance.
>
> Thanks
>
> Arvid
>
> > -Original Message-
> > From: dev-security-policy  >
> On
> > Behalf Of Nick Lamb via dev-security-policy
> > Sent: donderdag 11 februari 2021 19:12
> > To: dev-security-policy@lists.mozilla.org
> > Cc: Ben Wilson 
> > Subject: Re: Public Discussion of GlobalSign's CA Inclusion Request for
> R46,
> > E46, R45 and E45 Roots
> >
> > On Tue, 9 Feb 2021 14:29:15 -0700
> > Ben Wilson via dev-security-policy
> >  wrote:
> >
> > > All,
> > > GlobalSign has provided a very detailed incident report in Bugzilla -
> > > see https://bugzilla.mozilla.org/show_bug.cgi?id=1690807#c2.
> > > There are a few remaining questions that still need to be answered, so
> > > this email is just to keep you aware.
> > > Hopefully later this week I'll be able to come back and see if people
> > > are satisfied and whether we can proceed with the root inclusion
> > > request.
> >
> > I have a question (if I should write it in Bugzilla instead please say so
> it is unclear
> > to me what the correct protocol is)
> >
> > GlobalSign have provided a list of 112 other certificates which were
> issued for the
> > same reason, I examined some of them manually and determined that they
> are
> in
> > appearance unextraordinary (2048-bit RSA keys for example) and so it's
> > unsurprising we didn't notice they were issued previously.
> >
> > However, the list does not tell me when these certificates were ordered
> or, if
> > substantially different, when the email used to "validate" these orders
> was sent.
> >
> > As a result it's hard to be sure whether these certificates were issued
> perhaps
> > only a few weeks after they were ordered, which is a relatively minor
> oversight,
> > or, like the incident certificate, many years afterwards. I'd like maybe
> a
> column of
> > "order date" and "email sent date" if the two can be different.
> >
> > -
> >
> > I also have noticed something that definitely isn't (just) for
> GlobalSign.
> It seems to
> > me that the current Ten Blessed Methods do not tell issuers to prevent
> robots
> > from "clicking" email links. We don't need a CAPTCHA, just a "Yes I want
> this
> > certificate" POST form ought to be enough to defuse typical "anti-virus",
> "anti-
> > malware" or automated crawling/ cache building robots. Maybe I just
> missed
> > where the BRs tell you to prevent that, and hopefully even without
> prompting all
> > issuers using the email-based Blessed Methods have prevented this,
> >
> >
> > Nick.
> > ___
> > 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: Public Discussion of GlobalSign's CA Inclusion Request for R46, E46, R45 and E45 Roots

[Arvid Vermote via dev-security-policy]

Hi Nick 

We attached an updated version of the affected certificate overview to the
bug on February 10, which does contain the date of order and date of
issuance. 

Thanks

Arvid

> -Original Message-
> From: dev-security-policy 
On
> Behalf Of Nick Lamb via dev-security-policy
> Sent: donderdag 11 februari 2021 19:12
> To: dev-security-policy@lists.mozilla.org
> Cc: Ben Wilson 
> Subject: Re: Public Discussion of GlobalSign's CA Inclusion Request for
R46,
> E46, R45 and E45 Roots
> 
> On Tue, 9 Feb 2021 14:29:15 -0700
> Ben Wilson via dev-security-policy
>  wrote:
> 
> > All,
> > GlobalSign has provided a very detailed incident report in Bugzilla -
> > see https://bugzilla.mozilla.org/show_bug.cgi?id=1690807#c2.
> > There are a few remaining questions that still need to be answered, so
> > this email is just to keep you aware.
> > Hopefully later this week I'll be able to come back and see if people
> > are satisfied and whether we can proceed with the root inclusion
> > request.
> 
> I have a question (if I should write it in Bugzilla instead please say so
it is unclear
> to me what the correct protocol is)
> 
> GlobalSign have provided a list of 112 other certificates which were
issued for the
> same reason, I examined some of them manually and determined that they are
in
> appearance unextraordinary (2048-bit RSA keys for example) and so it's
> unsurprising we didn't notice they were issued previously.
> 
> However, the list does not tell me when these certificates were ordered
or, if
> substantially different, when the email used to "validate" these orders
was sent.
> 
> As a result it's hard to be sure whether these certificates were issued
perhaps
> only a few weeks after they were ordered, which is a relatively minor
oversight,
> or, like the incident certificate, many years afterwards. I'd like maybe a
column of
> "order date" and "email sent date" if the two can be different.
> 
> -
> 
> I also have noticed something that definitely isn't (just) for GlobalSign.
It seems to
> me that the current Ten Blessed Methods do not tell issuers to prevent
robots
> from "clicking" email links. We don't need a CAPTCHA, just a "Yes I want
this
> certificate" POST form ought to be enough to defuse typical "anti-virus",
"anti-
> malware" or automated crawling/ cache building robots. Maybe I just missed
> where the BRs tell you to prevent that, and hopefully even without
prompting all
> issuers using the email-based Blessed Methods have prevented this,
> 
> 
> Nick.
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy


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

Re: Public Discussion of GlobalSign's CA Inclusion Request for R46, E46, R45 and E45 Roots

[Ryan Sleevi via dev-security-policy]

On Thu, Feb 11, 2021 at 1:11 PM Nick Lamb via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> I have a question (if I should write it in Bugzilla instead please say
> so it is unclear to me what the correct protocol is)
>

While Mozilla Policy permits discussion in both, I will say it's
significantly easier when the discussion is on Bugzilla to ensure the
feedback is considered and promptly responded to. So if you want to
consider posing your questions there, that's really helpful for posterity.
If, for example, it became necessary to discuss a set of issues for a CA,
Bugzilla incident reports are going to be the primary source of the
incident report and discussion, and unless there's a clear link *on the
bug* to such mailing list discussion, it will no doubt be overlooked.

So I'd say feel free to ask your question there, which helps make sure it's
answered before the issue is closed.


> I also have noticed something that definitely isn't (just) for
> GlobalSign. It seems to me that the current Ten Blessed Methods do not
> tell issuers to prevent robots from "clicking" email links. We don't
> need a CAPTCHA, just a "Yes I want this certificate" POST form ought to
> be enough to defuse typical "anti-virus", "anti-malware" or automated
> crawling/ cache building robots. Maybe I just missed where the BRs
> tell you to prevent that, and hopefully even without prompting all
> issuers using the email-based Blessed Methods have prevented this,
>

Yes, this has been raised previously in the Forum by Peter Bowen (then at
Amazon), as part of the discussion and input with respect to the validation
methods. This is one of many outstanding items still for the Validation
Working Group of the CA/B Forum, as possible mitigations were also
discussed. In short, "capability URLs" (where the entire URL is, in effect,
the capability) are dangerous.

Note that there have been far more than "Ten Blessed Methods" since those
discussions, so perhaps it's clearer to just say 3.2.2.4.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Public Discussion of GlobalSign's CA Inclusion Request for R46, E46, R45 and E45 Roots

[Nick Lamb via dev-security-policy]

On Tue, 9 Feb 2021 14:29:15 -0700
Ben Wilson via dev-security-policy
 wrote:

> All,
> GlobalSign has provided a very detailed incident report in Bugzilla -
> see https://bugzilla.mozilla.org/show_bug.cgi?id=1690807#c2.
> There are a few remaining questions that still need to be answered,
> so this email is just to keep you aware.
> Hopefully later this week I'll be able to come back and see if people
> are satisfied and whether we can proceed with the root inclusion
> request.

I have a question (if I should write it in Bugzilla instead please say
so it is unclear to me what the correct protocol is)

GlobalSign have provided a list of 112 other certificates which were
issued for the same reason, I examined some of them manually and
determined that they are in appearance unextraordinary (2048-bit RSA
keys for example) and so it's unsurprising we didn't notice they were
issued previously.

However, the list does not tell me when these certificates were ordered
or, if substantially different, when the email used to "validate" these
orders was sent.

As a result it's hard to be sure whether these certificates were issued
perhaps only a few weeks after they were ordered, which is a relatively
minor oversight, or, like the incident certificate, many years
afterwards. I'd like maybe a column of "order date" and "email sent
date" if the two can be different.

-

I also have noticed something that definitely isn't (just) for
GlobalSign. It seems to me that the current Ten Blessed Methods do not
tell issuers to prevent robots from "clicking" email links. We don't
need a CAPTCHA, just a "Yes I want this certificate" POST form ought to
be enough to defuse typical "anti-virus", "anti-malware" or automated
crawling/ cache building robots. Maybe I just missed where the BRs
tell you to prevent that, and hopefully even without prompting all
issuers using the email-based Blessed Methods have prevented this, 


Nick.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Public Discussion of GlobalSign's CA Inclusion Request for R46, E46, R45 and E45 Roots

[Ben Wilson via dev-security-policy]

All,
GlobalSign has provided a very detailed incident report in Bugzilla - see
https://bugzilla.mozilla.org/show_bug.cgi?id=1690807#c2.
There are a few remaining questions that still need to be answered, so this
email is just to keep you aware.
Hopefully later this week I'll be able to come back and see if people are
satisfied and whether we can proceed with the root inclusion request.
Sincerely,
Ben

On Fri, Feb 5, 2021 at 2:36 PM Ben Wilson  wrote:

> All,
> Under Step 10 of the https://wiki.mozilla.org/CA/Application_Process,
> this is notice of a "further question or concern" that has
> arisen concerning GlobalSign's issuance of a 1024-bit RSA certificate. See
> https://bugzilla.mozilla.org/show_bug.cgi?id=1690807. GlobalSign has
> indicated that it will provide an incident report by next Tuesday,
> 9-Feb-2021.
> Thanks,
> Ben
>
> On Tue, Feb 2, 2021 at 5:48 PM Ben Wilson  wrote:
>
>> On January 11, 2021, we began the public discussion period [Step 4 of the
>> Mozilla Root Store CA Application Process
>> ] for the
>> above-referenced GlobalSign inclusion request.
>>
>> *Summary of Discussion and Completion of Action Items [Steps 5-8]:*
>>
>> Recently, Ryan Sleevi noted that GlobalSign is transitioning to a better
>> Root CA hierarchy with single-purpose roots.  This will lead to less risk
>> due to fewer cross-dependencies from other uses of PKI. He also noted that
>> GlobalSign has improved the quality of its incident reporting and
>> remediation.  I agree on both of these points.
>>
>> While GlobalSign currently has six matters open in Bugzilla, none of
>> these should be a reason to delay approval of this inclusion request.
>>
>> 1591005  – the
>> relevant issuing CAs have been revoked (nearly closed, waiting on a final
>> key destruction report)
>>
>> 1649937  -
>> Incorrect OCSP Delegated Responder Certificate issue - GlobalSign ceased
>> including the OCSP signing EKU in any newly generated issuing CA
>> (approximately 10 remaining issuing CAs affected by issue are on schedule
>> to be revoked)
>>
>> 1651447  –  Delayed
>> CA revocation, per issue # 1649937 above (GlobalSign is switching over from
>> old to newer infrastructure, as described in this and other bugs)
>>
>> 1664328  - SHA-256
>> hash algorithm used with ECC P-384 key (almost closed, status update needed)
>>
>> 1667944  – Empty
>> SingleExtension in OCSP responses (migration to new OCSP responders nearly
>> completed)
>>
>> 1668007  – Country
>> name in stateOrProvinceName field (almost closed, status update needed)
>>
>> This is notice that I am closing public discussion [Step 9] and that it
>> is Mozilla’s intent to approve GlobalSign's request for inclusion [Step
>> 10].
>>
>> This begins a 7-day “last call” period for any final objections.
>>
>> Thanks,
>>
>> Ben
>>
>> On Mon, Feb 1, 2021 at 10:18 AM Ben Wilson  wrote:
>>
>>> This is a reminder that I will close discussion on this tomorrow.
>>>
>>> On Mon, Jan 11, 2021 at 5:59 PM Ben Wilson  wrote:
>>>
 This is to announce the beginning of the public discussion phase of the
 Mozilla root CA inclusion process for GlobalSign.

 See https://wiki.mozilla.org/CA/Application_Process#Process_Overview,
 (Steps 4 through 9).

 GlobalSign has four (4) new roots to include in the root store.  Two
 roots, one RSA and another ECC, are to support server authentication
 (Bugzilla Bug # 1570724
 ) while two
 other roots are for email authentication, RSA and ECC (Bugzilla Bug #
 1637269 ).

 Mozilla is considering approving GlobalSign’s request(s). This email
 begins the 3-week comment period, after which, if no concerns are raised,
 we will close the discussion and the request may proceed to the approval
 phase (Step 10).

 *A Summary of Information Gathered and Verified appears here in these
 two CCADB cases:*


 https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=0469


 https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=0596

 *Root Certificate Information:*

 *GlobalSign Root R46 *

 crt.sh -
 https://crt.sh/?q=4FA3126D8D3A11D1C4855A4F807CBAD6CF919D3A5A88B03BEA2C6372D93C40C9

 Download - https://secure.globalsign.com/cacert/rootr46.crt

 *GlobalSign Root E46*

 crt.sh -
 https://crt.sh/?q=CBB9C44D84B8043E1050EA31A69F514955D7BFD2E2C6B49301019AD61D9F5058

 Download - 

Re: Public Discussion of GlobalSign's CA Inclusion Request for R46, E46, R45 and E45 Roots

[Ben Wilson via dev-security-policy]

All,
Under Step 10 of the https://wiki.mozilla.org/CA/Application_Process, this
is notice of a "further question or concern" that has arisen concerning
GlobalSign's issuance of a 1024-bit RSA certificate. See
https://bugzilla.mozilla.org/show_bug.cgi?id=1690807. GlobalSign has
indicated that it will provide an incident report by next Tuesday,
9-Feb-2021.
Thanks,
Ben

On Tue, Feb 2, 2021 at 5:48 PM Ben Wilson  wrote:

> On January 11, 2021, we began the public discussion period [Step 4 of the
> Mozilla Root Store CA Application Process
> ] for the
> above-referenced GlobalSign inclusion request.
>
> *Summary of Discussion and Completion of Action Items [Steps 5-8]:*
>
> Recently, Ryan Sleevi noted that GlobalSign is transitioning to a better
> Root CA hierarchy with single-purpose roots.  This will lead to less risk
> due to fewer cross-dependencies from other uses of PKI. He also noted that
> GlobalSign has improved the quality of its incident reporting and
> remediation.  I agree on both of these points.
>
> While GlobalSign currently has six matters open in Bugzilla, none of these
> should be a reason to delay approval of this inclusion request.
>
> 1591005  – the
> relevant issuing CAs have been revoked (nearly closed, waiting on a final
> key destruction report)
>
> 1649937  -
> Incorrect OCSP Delegated Responder Certificate issue - GlobalSign ceased
> including the OCSP signing EKU in any newly generated issuing CA
> (approximately 10 remaining issuing CAs affected by issue are on schedule
> to be revoked)
>
> 1651447  –  Delayed
> CA revocation, per issue # 1649937 above (GlobalSign is switching over from
> old to newer infrastructure, as described in this and other bugs)
>
> 1664328  - SHA-256
> hash algorithm used with ECC P-384 key (almost closed, status update needed)
>
> 1667944  – Empty
> SingleExtension in OCSP responses (migration to new OCSP responders nearly
> completed)
>
> 1668007  – Country
> name in stateOrProvinceName field (almost closed, status update needed)
>
> This is notice that I am closing public discussion [Step 9] and that it is
> Mozilla’s intent to approve GlobalSign's request for inclusion [Step 10].
>
>
> This begins a 7-day “last call” period for any final objections.
>
> Thanks,
>
> Ben
>
> On Mon, Feb 1, 2021 at 10:18 AM Ben Wilson  wrote:
>
>> This is a reminder that I will close discussion on this tomorrow.
>>
>> On Mon, Jan 11, 2021 at 5:59 PM Ben Wilson  wrote:
>>
>>> This is to announce the beginning of the public discussion phase of the
>>> Mozilla root CA inclusion process for GlobalSign.
>>>
>>> See https://wiki.mozilla.org/CA/Application_Process#Process_Overview,
>>> (Steps 4 through 9).
>>>
>>> GlobalSign has four (4) new roots to include in the root store.  Two
>>> roots, one RSA and another ECC, are to support server authentication
>>> (Bugzilla Bug # 1570724
>>> ) while two other
>>> roots are for email authentication, RSA and ECC (Bugzilla Bug # 1637269
>>> ).
>>>
>>> Mozilla is considering approving GlobalSign’s request(s). This email
>>> begins the 3-week comment period, after which, if no concerns are raised,
>>> we will close the discussion and the request may proceed to the approval
>>> phase (Step 10).
>>>
>>> *A Summary of Information Gathered and Verified appears here in these
>>> two CCADB cases:*
>>>
>>>
>>> https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=0469
>>>
>>>
>>> https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=0596
>>>
>>> *Root Certificate Information:*
>>>
>>> *GlobalSign Root R46 *
>>>
>>> crt.sh -
>>> https://crt.sh/?q=4FA3126D8D3A11D1C4855A4F807CBAD6CF919D3A5A88B03BEA2C6372D93C40C9
>>>
>>> Download - https://secure.globalsign.com/cacert/rootr46.crt
>>>
>>> *GlobalSign Root E46*
>>>
>>> crt.sh -
>>> https://crt.sh/?q=CBB9C44D84B8043E1050EA31A69F514955D7BFD2E2C6B49301019AD61D9F5058
>>>
>>> Download - https://secure.globalsign.com/cacert/roote46.crt
>>>
>>> *GlobalSign Secure Mail Root R45 *
>>>
>>> crt.sh -
>>> https://crt.sh/?q=319AF0A7729E6F89269C131EA6A3A16FCD86389FDCAB3C47A4A675C161A3F974
>>>
>>> Download - https://secure.globalsign.com/cacert/smimerootr45.crt
>>>
>>> *GlobalSign Secure Mail Root E45 *
>>>
>>> crt.sh -
>>> https://crt.sh/?q=5CBF6FB81FD417EA4128CD6F8172A3C9402094F74AB2ED3A06B4405D04F30B19
>>>
>>> Download - https://secure.globalsign.com/cacert/smimeroote45.crt
>>>
>>>
>>> *CP/CPS:*
>>>
>>> https://www.globalsign.com/en/repository/GlobalSign_CPS_v9.6_final.pdf
>>>
>>> 

Re: Public Discussion of GlobalSign's CA Inclusion Request for R46, E46, R45 and E45 Roots

[Ben Wilson via dev-security-policy]

On January 11, 2021, we began the public discussion period [Step 4 of the
Mozilla Root Store CA Application Process
] for the
above-referenced GlobalSign
inclusion request.

*Summary of Discussion and Completion of Action Items [Steps 5-8]:*

Recently, Ryan Sleevi noted that GlobalSign is transitioning to a better
Root CA hierarchy with single-purpose roots.  This will lead to less risk
due to fewer cross-dependencies from other uses of PKI. He also noted that
GlobalSign has improved the quality of its incident reporting and
remediation.  I agree on both of these points.

While GlobalSign currently has six matters open in Bugzilla, none of these
should be a reason to delay approval of this inclusion request.

1591005  – the
relevant issuing CAs have been revoked (nearly closed, waiting on a final
key destruction report)

1649937  - Incorrect
OCSP Delegated Responder Certificate issue - GlobalSign ceased including
the OCSP signing EKU in any newly generated issuing CA (approximately 10
remaining issuing CAs affected by issue are on schedule to be revoked)

1651447  –  Delayed
CA revocation, per issue # 1649937 above (GlobalSign is switching over from
old to newer infrastructure, as described in this and other bugs)

1664328  - SHA-256
hash algorithm used with ECC P-384 key (almost closed, status update needed)

1667944  – Empty
SingleExtension in OCSP responses (migration to new OCSP responders nearly
completed)

1668007  – Country
name in stateOrProvinceName field (almost closed, status update needed)

This is notice that I am closing public discussion [Step 9] and that it is
Mozilla’s intent to approve GlobalSign's request for inclusion [Step 10].

This begins a 7-day “last call” period for any final objections.

Thanks,

Ben

On Mon, Feb 1, 2021 at 10:18 AM Ben Wilson  wrote:

> This is a reminder that I will close discussion on this tomorrow.
>
> On Mon, Jan 11, 2021 at 5:59 PM Ben Wilson  wrote:
>
>> This is to announce the beginning of the public discussion phase of the
>> Mozilla root CA inclusion process for GlobalSign.
>>
>> See https://wiki.mozilla.org/CA/Application_Process#Process_Overview,
>> (Steps 4 through 9).
>>
>> GlobalSign has four (4) new roots to include in the root store.  Two
>> roots, one RSA and another ECC, are to support server authentication
>> (Bugzilla Bug # 1570724
>> ) while two other
>> roots are for email authentication, RSA and ECC (Bugzilla Bug # 1637269
>> ).
>>
>> Mozilla is considering approving GlobalSign’s request(s). This email
>> begins the 3-week comment period, after which, if no concerns are raised,
>> we will close the discussion and the request may proceed to the approval
>> phase (Step 10).
>>
>> *A Summary of Information Gathered and Verified appears here in these two
>> CCADB cases:*
>>
>>
>> https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=0469
>>
>>
>> https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=0596
>>
>> *Root Certificate Information:*
>>
>> *GlobalSign Root R46 *
>>
>> crt.sh -
>> https://crt.sh/?q=4FA3126D8D3A11D1C4855A4F807CBAD6CF919D3A5A88B03BEA2C6372D93C40C9
>>
>> Download - https://secure.globalsign.com/cacert/rootr46.crt
>>
>> *GlobalSign Root E46*
>>
>> crt.sh -
>> https://crt.sh/?q=CBB9C44D84B8043E1050EA31A69F514955D7BFD2E2C6B49301019AD61D9F5058
>>
>> Download - https://secure.globalsign.com/cacert/roote46.crt
>>
>> *GlobalSign Secure Mail Root R45 *
>>
>> crt.sh -
>> https://crt.sh/?q=319AF0A7729E6F89269C131EA6A3A16FCD86389FDCAB3C47A4A675C161A3F974
>>
>> Download - https://secure.globalsign.com/cacert/smimerootr45.crt
>>
>> *GlobalSign Secure Mail Root E45 *
>>
>> crt.sh -
>> https://crt.sh/?q=5CBF6FB81FD417EA4128CD6F8172A3C9402094F74AB2ED3A06B4405D04F30B19
>>
>> Download - https://secure.globalsign.com/cacert/smimeroote45.crt
>>
>>
>> *CP/CPS:*
>>
>> https://www.globalsign.com/en/repository/GlobalSign_CPS_v9.6_final.pdf
>>
>> The current GlobalSign CPS is version 9.6, published 29-December-2020.
>>
>> Repository location: https://www.globalsign.com/en/repository
>>
>> *BR Self-Assessment* (Excel) is located here:
>>
>> https://bugzilla.mozilla.org/attachment.cgi?id=9082310
>>
>> *Audits:*  GlobalSign is audited annually in accordance with the
>> WebTrust criteria by Ernst & Young, Belgium, which found in June 2020 that
>> “throughout the period April 1, 2019 to March 31, 2020, GlobalSign
>> management’s assertion, as referred to above, is fairly stated, in all
>> material respects, in 

Re: Public Discussion of GlobalSign's CA Inclusion Request for R46, E46, R45 and E45 Roots

[Ben Wilson via dev-security-policy]

This is a reminder that I will close discussion on this tomorrow.

On Mon, Jan 11, 2021 at 5:59 PM Ben Wilson  wrote:

> This is to announce the beginning of the public discussion phase of the
> Mozilla root CA inclusion process for GlobalSign.
>
> See https://wiki.mozilla.org/CA/Application_Process#Process_Overview,
> (Steps 4 through 9).
>
> GlobalSign has four (4) new roots to include in the root store.  Two
> roots, one RSA and another ECC, are to support server authentication
> (Bugzilla Bug # 1570724
> ) while two other
> roots are for email authentication, RSA and ECC (Bugzilla Bug # 1637269
> ).
>
> Mozilla is considering approving GlobalSign’s request(s). This email
> begins the 3-week comment period, after which, if no concerns are raised,
> we will close the discussion and the request may proceed to the approval
> phase (Step 10).
>
> *A Summary of Information Gathered and Verified appears here in these two
> CCADB cases:*
>
>
> https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=0469
>
>
> https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=0596
>
> *Root Certificate Information:*
>
> *GlobalSign Root R46 *
>
> crt.sh -
> https://crt.sh/?q=4FA3126D8D3A11D1C4855A4F807CBAD6CF919D3A5A88B03BEA2C6372D93C40C9
>
> Download - https://secure.globalsign.com/cacert/rootr46.crt
>
> *GlobalSign Root E46*
>
> crt.sh -
> https://crt.sh/?q=CBB9C44D84B8043E1050EA31A69F514955D7BFD2E2C6B49301019AD61D9F5058
>
> Download - https://secure.globalsign.com/cacert/roote46.crt
>
> *GlobalSign Secure Mail Root R45 *
>
> crt.sh -
> https://crt.sh/?q=319AF0A7729E6F89269C131EA6A3A16FCD86389FDCAB3C47A4A675C161A3F974
>
> Download - https://secure.globalsign.com/cacert/smimerootr45.crt
>
> *GlobalSign Secure Mail Root E45 *
>
> crt.sh -
> https://crt.sh/?q=5CBF6FB81FD417EA4128CD6F8172A3C9402094F74AB2ED3A06B4405D04F30B19
>
> Download - https://secure.globalsign.com/cacert/smimeroote45.crt
>
>
> *CP/CPS:*
>
> https://www.globalsign.com/en/repository/GlobalSign_CPS_v9.6_final.pdf
>
> The current GlobalSign CPS is version 9.6, published 29-December-2020.
>
> Repository location: https://www.globalsign.com/en/repository
>
> *BR Self-Assessment* (Excel) is located here:
>
> https://bugzilla.mozilla.org/attachment.cgi?id=9082310
>
> *Audits:*  GlobalSign is audited annually in accordance with the WebTrust
> criteria by Ernst & Young, Belgium, which found in June 2020 that
> “throughout the period April 1, 2019 to March 31, 2020, GlobalSign
> management’s assertion, as referred to above, is fairly stated, in all
> material respects, in accordance with the WebTrust Principles and Criteria
> for Certification Authorities - SSL Baseline with Network Security, Version
> 2.3.”  The WebTrust audit noted the following 13 Bugzilla incidents,
> which had been previously reported as of that audit date:
>
> 1 Misissuance of QWAC certificates.
>
> 2 Issue with an OCSP responder status.
>
> 3 Some SSL certificates with US country code and invalid State/Prov have
> been issued.
>
> 4 ICAs in CCADB, without EKU extension are listed in WTCA report but not
> in WTBR report.
>
> 5 OCSP responders found to respond signed by the default CA when passed an
> invalid issuer in request.
>
> 6 Wrong business category on 3 EV SSL certificates.
>
> 7 OCSP Responder returned invalid values for some precertificates.
>
> 8 Customer running an on-premise (technically-constrained) CA that chains
> to a GlobalSign root, issued certificates without AIA extension.
>
> 9 Misissued 4 certificates with invalid CN.
>
> 10 Certificates with Subject Public Key Info lacking the explicit NULL
> parameter.
>
> 11 Untimely revocation of TLS certificate after submission of private key
> compromise.
>
> 12 Unable to revoke 2 noncompliant QWACs within 5 days.
>
> 13 Unable to revoke noncompliant ICA within 7 days
>
>
>
> *Incident Reports / Mis-Issuances *
>
> The following bugs/incidents remain open and are being worked on.
>
> 1667944 
>
> Empty SingleExtension in OCSP responses
> 
>
> 1651447 
>
> Failure to revoke noncompliant ICA within 7 days
> 
>
> 1591005 
>
> ICAs in CCADB, without EKU extension are listed in WTCA report but not in
> WTBR report 
>
> 1649937 
>
> Incorrect OCSP Delegated Responder Certificate
> 
>
> 1668007 
>
> Invalid stateOrProvinceName value
> 
>
> 

Re: Public Discussion of GlobalSign's CA Inclusion Request for R46, E46, R45 and E45 Roots

[Ryan Sleevi via dev-security-policy]

Hey Ben,

I know discussion here has been quiet, but in light of other threads going
on, I actually want to say I'm very supportive of GlobalSign's plan here,
and surprised they didn't call more attention to it, because it's something
to be proud of.

As I understand it, and happy to be corrected if I've made a mistake here,
GlobalSign is actively working to transition their hierarchy to one that
reflects a modern, good practice implementation. That's something they
should be proud of, and something all CAs should take note of. In
particular, they're transitioning to single-purpose roots (e.g. all TLS,
all e-mail), in order to reduce the risk to relying parties from roots that
exist cross-purposes.

You're absolutely correct for calling out GlobalSign's past incidents, and
I don't want to appear to be suggesting that simply spinning up new roots
wipes the old slate clean, but this is a huge step in the right direction,
and does reflect good practice. I will disclose that GlobalSign reached
out, as have several other CAs (PKIoverheid, Sectigo, DigiCert), to invite
feedback in their design and discuss some of their challenges, and I think
that's also the kind of positive, proactive behavior worth encouraging.

Within the context of the incident reports, I do want to also acknowledge
that GlobalSign has consistently improved the quality of their reports. As
the OCSP issue shows, the level of detail and clarity in their
communications, and their providing artifacts, has been a huge help in
addressing and assuaging concerns. Rather than purely looking at the number
of incidents, and instead looking at how the incident reports are handled,
this is good progress. While some bugs did feel like they dragged out (e.g.
1575880), even then, GlobalSign was proactive in communicating both the
completion of past actions as well as next steps, with clear timetables.

GlobalSign has already proactively addressed some of the other things one
might expect from a "modern" CA - for example, supporting and enabling
automation for their customers, both "retail" and "managed CA/Enterprise"
(via AEG), and so I do see a positive trend in addressing some of the
systemic issues here.

That's not to say things are perfect: for example, the mixing of TLS
profiles (DV, OV, EV) in a single hierarchy means that there are still a
number of systemic risks which we've seen as patterns, both from GlobalSign
and other CAs, in terms of audit and audit scopes and proper validation of
information, but I do think this is trending closer to what would be good
for all CAs  to think about.

The sooner we can get to sunsetting GlobalSign's legacy roots, the better,
and so I definitely think it would be encouraging to see them help migrate
customers sooner than waiting on natural expiration alone, just like I
think continuing to shorten lifetimes would be another very positive sign.
However, I understand and recognize there are complexities here that may
prevent that, but I didn't want folks to think this was "as good as it
gets" ;)

On Mon, Jan 11, 2021 at 7:59 PM Ben Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> This is to announce the beginning of the public discussion phase of the
> Mozilla root CA inclusion process for GlobalSign.
>
> See https://wiki.mozilla.org/CA/Application_Process#Process_Overview,
> (Steps 4 through 9).
>
> GlobalSign has four (4) new roots to include in the root store.  Two roots,
> one RSA and another ECC, are to support server authentication (Bugzilla Bug
> # 1570724 ) while
> two
> other roots are for email authentication, RSA and ECC (Bugzilla Bug #
> 1637269 ).
>
> Mozilla is considering approving GlobalSign’s request(s). This email begins
> the 3-week comment period, after which, if no concerns are raised, we will
> close the discussion and the request may proceed to the approval phase
> (Step 10).
>
> *A Summary of Information Gathered and Verified appears here in these two
> CCADB cases:*
>
>
> https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=0469
>
>
> https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=0596
>
> *Root Certificate Information:*
>
> *GlobalSign Root R46 *
>
> crt.sh -
>
> https://crt.sh/?q=4FA3126D8D3A11D1C4855A4F807CBAD6CF919D3A5A88B03BEA2C6372D93C40C9
>
> Download - https://secure.globalsign.com/cacert/rootr46.crt
>
> *GlobalSign Root E46*
>
> crt.sh -
>
> https://crt.sh/?q=CBB9C44D84B8043E1050EA31A69F514955D7BFD2E2C6B49301019AD61D9F5058
>
> Download - https://secure.globalsign.com/cacert/roote46.crt
>
> *GlobalSign Secure Mail Root R45 *
>
> crt.sh -
>
> https://crt.sh/?q=319AF0A7729E6F89269C131EA6A3A16FCD86389FDCAB3C47A4A675C161A3F974
>
> Download - https://secure.globalsign.com/cacert/smimerootr45.crt
>
> *GlobalSign Secure Mail Root E45 *
>
> crt.sh -
>
>