1349727 - Add GlobalSign Extended Validation CA - SHA256 - G2 cert to NSS

Status: RESOLVED WONTFIX

(NSS :: CA Certificates Code, task)

Description

[Kathleen Wilson]

Attachment: GlobalSign-SHA-256-G2-EV.cer

This bug is a special circumstance in which an intermediate certificate will be added to the root store during a transition time.

As explained in bug #1347882, Google Trust Services (GTS) recently purchased two roots from GlobalSign that are both enabled for EV treatment: "GlobalSign Root CA - R2" and "GlobalSign Root CA - R4".

However, GTS does not have an EV audit, so we are going to turn off EV treatment for both of those root certificates.

But "GlobalSign Root CA - R2" has intermediate cert "GlobalSign Extended Validation CA - SHA256 - G2" that continues to be controlled by GlobalSign, to be used to migrate their customers off dependence on that root. 

So, we are requesting that the "GlobalSign Extended Validation CA - SHA256 - G2" intermediate cert be added to the root store, so we can enable it for EV treatment, and then turn off EV treatment for "GlobalSign Root CA - R2".

Therefore, please add the following certificate, owned by GlobalSign, to the NSS root store.


Friendly Name: GlobalSign Extended Validation CA - SHA256 - G2
Cert Location: https://crt.sh/?id=3722345
SHA-1 Fingerprint: 65:BE:10:2B:E2:69:28:65:0E:0E:F5:4D:C8:F4:F1:5A:F5:F9:8E:8B
SHA-256 Fingerprint:
24:F9:1C:07:05:A0:A5:33:86:41:B3:65:FB:0D:9D:97:09:B5:62:97:CF:F1:85:7E:73:C0:2C:16:36:D4:86:AA
Trust Flags: Websites
Test URL: https://2021.globalsign.com/

This CA has previously been assessed in accordance with the Mozilla project guidelines, and the certificates approved for inclusion in bug #367245. 

The next steps are as follows:
1) A representative of the CA must confirm that all the data in this bug is correct, and that the correct certificate has been attached.
2) A Mozilla representative creates a patch with the new certificate, and provides a special test version of Firefox.
3) A representative of the CA uses the test version of Firefox to confirm (by adding a comment in this bug) that the certificate has been correctly imported and that websites work correctly.
4) The Mozilla representative requests that another Mozilla representative review the patch.
5) The Mozilla representative adds (commits) the patch to NSS, then closes this bug as RESOLVED FIXED.
6) At some time after that, various Mozilla products will move to using a version of NSS which contains the certificates. This process is mostly under the control of the release drivers for those products.

Comment 1

[Kathleen Wilson]

Doug, please see step #1 above, and add a comment to this bug to confirm if the data is correct.

Comment 2

[Kathleen Wilson]

Gerv, since this is a special case, I would appreciate it if you will also review the data in this bug and add a comment to confirm if the data is correct.

Comment 3

[douglas.beattie]

I can confirm that #1 is correct.

Comment 4

[Gervase Markham [:gerv]]

This LGTM.

Gerv

Comment 5

[Kathleen Wilson]

Thanks Doug and Gerv!

Comment 6

[Kai Engert (:KaiE:)]

The only reason why you request this intermediate to be marked as trusted in NSS is because you'd like to mark it as EV inside of Firefox/PSM, is this correct?

If yes, could you rather change the Firefox/PSM code, to be able to accept an intermediate CA as whitelisted for EV, and mark this trust addition as wontfix?


Isn't there a rule, that all end entity certificates must be issued from an intermediate? If we marked the attached intermediate as trusted, it would effectively turn it into a root CA. As a result, the already issued end entity certificates would no longer follow the mentioned rule, because they have been issued by a CA certificate that's effectively a root CA.

Comment 7

[Ryan Sleevi]

(In reply to Kai Engert (:kaie) from comment #6)
> The only reason why you request this intermediate to be marked as trusted in
> NSS is because you'd like to mark it as EV inside of Firefox/PSM, is this
> correct?

Unclear if you're asking that to Kathleen or to Doug. Could you clarify, based on Comment 0, who that's addressed to?

> If yes, could you rather change the Firefox/PSM code, to be able to accept
> an intermediate CA as whitelisted for EV, and mark this trust addition as
> wontfix?

Unclear if you're asking that to Kathleen or to David. Could you clarify who that's addressed to?

> Isn't there a rule, that all end entity certificates must be issued from an
> intermediate? 

Unclear whether you're asking if there is a Baseline Requirements rule, or whether there is a rule within NSS/mozilla::pkix. Could you clarify?

> If we marked the attached intermediate as trusted, it would
> effectively turn it into a root CA. As a result, the already issued end
> entity certificates would no longer follow the mentioned rule, because they
> have been issued by a CA certificate that's effectively a root CA.

Given the above uncertainty, it's unclear whether you're stating a belief that mozilla::pkix/NSS does not support certificates issued by "trust anchors" (which it was designed to, and which is necessary code to support enterprise operations and trust management) or a belief that this would somehow change the scope of the Baseline Requirements. Could you clarify?

Comment 8

[Kai Engert (:KaiE:)]

(In reply to Ryan Sleevi from comment #7)
> (In reply to Kai Engert (:kaie) from comment #6)
> > The only reason why you request this intermediate to be marked as trusted in
> > NSS is because you'd like to mark it as EV inside of Firefox/PSM, is this
> > correct?
> 
> Unclear if you're asking that to Kathleen or to Doug. Could you clarify,
> based on Comment 0, who that's addressed to?

My question is for Kathleen. It seems to me, that currently, the issueing CA certificate will kept as trusted. If correct, the explicit trust flag seems unnecessary.

The question is, is this request based on an assumption, that it might be required for technical EV treatment in Mozilla software?



> > If yes, could you rather change the Firefox/PSM code, to be able to accept
> > an intermediate CA as whitelisted for EV, and mark this trust addition as
> > wontfix?
> 
> Unclear if you're asking that to Kathleen or to David. Could you clarify who
> that's addressed to?

Question directed to technical engineering of Firefox/PSM code. I'm asking Kathleen, if she has already considered this option, and if she has already discussed this with Firefox/PSM engineering. If not, this is a suggestion to do so.


> 
> > Isn't there a rule, that all end entity certificates must be issued from an
> > intermediate? 
> 
> Unclear whether you're asking if there is a Baseline Requirements rule, or
> whether there is a rule within NSS/mozilla::pkix. Could you clarify?

I have a vague memory that a rule similar to this existed in the past.
I'm asking if such a rule exists that applies to this context.


Marking the attached intermediate as a trust anchor, would result in the end entity certificates having been issued directly by a trust anchor, not having been issued by an intermediate that was issued by a trust anchor. I'm asking if this is permitted. I'm making this comment, in case such a rule indeed exists, to create awareness of this technical detail, in case nobody had yet noticed this consequence.

Comment 9

[Kathleen Wilson]

(In reply to Kai Engert (:kaie) from comment #8)
> (In reply to Ryan Sleevi from comment #7)
> > (In reply to Kai Engert (:kaie) from comment #6)
> > > The only reason why you request this intermediate to be marked as trusted in
> > > NSS is because you'd like to mark it as EV inside of Firefox/PSM, is this
> > > correct?
> > 
> > Unclear if you're asking that to Kathleen or to Doug. Could you clarify,
> > based on Comment 0, who that's addressed to?
> 
> My question is for Kathleen. It seems to me, that currently, the issueing CA
> certificate will kept as trusted. If correct, the explicit trust flag seems
> unnecessary.
> 
> The question is, is this request based on an assumption, that it might be
> required for technical EV treatment in Mozilla software?

Yes. My understanding is that we can only enable EV treatment for certificates in the NSS root store.

> 
> 
> 
> > > If yes, could you rather change the Firefox/PSM code, to be able to accept
> > > an intermediate CA as whitelisted for EV, and mark this trust addition as
> > > wontfix?
> > 
> > Unclear if you're asking that to Kathleen or to David. Could you clarify who
> > that's addressed to?
> 
> Question directed to technical engineering of Firefox/PSM code. I'm asking
> Kathleen, if she has already considered this option, and if she has already
> discussed this with Firefox/PSM engineering. If not, this is a suggestion to
> do so.


I did not ask anyone about changing the behavior of Firefox/PSM to be able to enable EV treatment for intermediate certs. That is a good question.

Keeler, would it be reasonable to go that route? Should I file a different bug for that?


> Marking the attached intermediate as a trust anchor, would result in the end
> entity certificates having been issued directly by a trust anchor, not
> having been issued by an intermediate that was issued by a trust anchor. I'm
> asking if this is permitted. I'm making this comment, in case such a rule
> indeed exists, to create awareness of this technical detail, in case nobody
> had yet noticed this consequence.

We have allowed intermediate certs to be included as trust anchors, under certain circumstances, such as:
https://wiki.mozilla.org/CA:SubordinateCA_checklist#Super-CAs

Comment 10

[Kai Engert (:KaiE:)]

(In reply to Kathleen Wilson from comment #9)
> 
> > Marking the attached intermediate as a trust anchor, would result in the end
> > entity certificates having been issued directly by a trust anchor, not
> > having been issued by an intermediate that was issued by a trust anchor. I'm
> > asking if this is permitted. I'm making this comment, in case such a rule
> > indeed exists, to create awareness of this technical detail, in case nobody
> > had yet noticed this consequence.
> 
> We have allowed intermediate certs to be included as trust anchors, under
> certain circumstances, such as:
> https://wiki.mozilla.org/CA:SubordinateCA_checklist#Super-CAs

Thank you for confirming this is allowed.

(I had not noticed that we have any intermediate CAs marked as trusted. As of today, there seems to be exactly one in the Mozilla trust list: The PSCProcert that had been added in bug 810010. The test site for this bug is still alive, and although the test certificate has expired, it shows that it was issued directly by the included intermediate.)

Comment 11

[Kai Engert (:KaiE:)]

(In reply to Kathleen Wilson from comment #9)
> 
> I did not ask anyone about changing the behavior of Firefox/PSM to be able
> to enable EV treatment for intermediate certs. That is a good question.
> 
> Keeler, would it be reasonable to go that route? Should I file a different
> bug for that?


In bug 1349762, which requests EV enablement, I have suggested to perform an experiment, to draw a conclusion how this bug should be handled. See bug 1349762 comment 1.

Comment 12

[douglas.beattie]

All EV certificates under this CA will expire 27 months from 10/31/2016 (which is about 1/2019).  I don't know if Google has any plans to issue EV certificates, but if they do eventually, it's likely to take a year or more.  If it's hard or risky to change the trust bits around now, maybe you can leave it as is and update only if Google intents to issue EV under this root.

Just a thought.

Comment 13

[Kathleen Wilson]

We cannot leave a root certificate enabled for EV treatment when its private key is owned and operated by an organization that is not getting audited for EV. So, we have to do something about it.

As for actual implementation in code, I see three options:

Option 1) Remove EV treatment from the root cert, and just let all the certs signed by the "GlobalSign Extended Validation CA - SHA256 - G2" certificate not get EV treatment. This is the least amount of work for Mozilla and NSS engineers. The only problem with this is the impact on GlobalSign's existing customers who paid for EV treatment. One could argue that this is not Mozilla's problem, but I think Mozilla folks are trying to be accommodating for the sake of the end users. However, I have not seen an estimate about how many users we are talking about. It is possible that it would be more efficient to have the CA issue new certs to those customers. Doug, how many end-entity certs are impacted?

Option 2) Add the intermediate cert to the NSS root store, enable it for EV treatment, and remove EV treatment from the root cert. The downside of this is having both a root and its intermediate cert in the NSS root store. We usually don't do this. However, this is how we will have to manage it in the Common CA Database -- treat the intermediate cert as a separate trust anchor, because a different organization (from the root) is required to annually provide updated audit, CP, CPS, test websites. So, perhaps this would be the most consistent way to go (if option 1 is not reasonable) -- it would mirror in code what is happening physically.
Note that the EV treatment would have to be tested, since we have not done this before.

Option 3) Update PSM to allow us to enable the intermediate cert for EV treatment without the cert being added to the NSS root store. Then enable it for EV treatment, and remove EV treatment from the root cert. The downside, is we do not yet know the scope of updating the PSM code to allow us to enable a cert for EV treatment that is not in the NSS root store. The upside, is that we do not add the intermediate cert to the NSS root store.

Comment 14

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

This can be accomplished in PSM, so option 3 is viable. However, I think it would be a good idea to investigate option 1 to see if the effort is worth the result.

Comment 15

[Kathleen Wilson]

Doug, please let us know how many EV SSL certs would be impacted if we remove EV treatment from the root cert without doing any further work, ie option 1 above.

Comment 16

[douglas.beattie]

We have approximately 10,000 active EV certificates under root R2.

Comment 17

[douglas.beattie]

Hi Kathleen,

Based on our prior discussions with Mozilla and Google we built our transition plan on allowing the gradual expiration of the existing 10k or so EV certificates issued by this subordinate CA. In support of the transition, we rolled out the new CA for issuance on 10/31/2016 and we have not issued any customer certificates from the R2 CA since that time.  The last EV SSL certificate expires in January 2019.

We would greatly appreciate Mozilla supporting us in this migration by implementing option #3 in the above list so these customers can continue to receive the EV treatment.  If necessary we can shorten the tail end of this by incenting customers to reissue their EV certificates, but we’d like to avoid this if possible.  If you feel shortening the period by 6-8 months will help, we can work with you on a plan.

This is a report on the current valid EV certificates under this root:

Expiry Month	# Certs
March-17	65
April-17	541
May-17		564
June-17		681
July-17		742
August-17	614
September-17	628
October-17	560
November-17	468
December-17	410
January-18	435
February-18	311
March-18	395
April-18	404
May-18	 	378
June-18		461
July-18		368
August-18	381
September-18	374
October-18	411
November-18	162
December-18	65
January-19	20

Comment 18

[Kathleen Wilson]

(In reply to David Keeler [:keeler] (use needinfo?) from comment #14)
> This can be accomplished in PSM, so option 3 is viable. However, I think it
> would be a good idea to investigate option 1 to see if the effort is worth
> the result.

David, please see Comment #16 and Comment #17.

It sounds like option #3 is our best approach.

> Option 3) Update PSM to allow us to enable the intermediate cert for EV 
> treatment without the cert being added to the NSS root store. Then enable 
> it for EV treatment, and remove EV treatment from the root cert. 

I had filed Bug #1349762 to enable EV treatment for the intermediate cert, and disable EV treatment for the root cert. 
Is that bug sufficient? 
Or should I file another bug to update PSM to allow for an intermediate cert (a cert not in the NSS root store) to be enabled for EV treatment?

Comment 19

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

I think at this point it would be best to special-case this intermediate and not build a new framework for something we're hopefully not going to do again. Bug 1349762 should be sufficient.

Comment 20

[Kathleen Wilson]

Closing this bug as WONTFIX, because we will *not* add this intermediate cert to NSS. We will instead handle the EV treatment via Bug #1349762 as a special case.