Add Re-Signed GTS Roots
Categories
(CA Program :: CA Certificate Root Program, task, P1)
Tracking
(Not tracked)
People
(Reporter: bwilson, Assigned: bwilson)
References
Details
(Whiteboard: [ca-approved] - In NSS 3.74, FF 97)
Google Trust Services (GTS) re-signed six Root CAs to create certificates with the digitalSignature bit to replace these six existing ones: GTS Root R3, GlobalSign Root CA - R2, GlobalSign ECC Root CA - R4, GTS Root R1, GTS Root R2, and GTS Root R4. Here is a link to the root inclusion case information listed in the CCADB - https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000666. Additional information is found in Bug #1667844.
|
Assignee | |
Updated•4 years ago
|
|
|
Assignee | |
Updated•3 years ago
|
Hello,
After these new root certificates are approved, will the old GTS root certificates be removed?
|
||
Comment 2•3 years ago
|
||
Andrew, it is not clear if the question is addressed to GTS or Mozilla. I suspect Mozilla, but wanted to provide a bit of information.
GTS has discussed this with Mozilla and is awaiting feedback on their preferred plan. For 5 of the roots in question, removal of the old version is fine as soon as the new root is included. We're aware of some pins to the legacy GlobalSign R2 root, especially for widely deployed embedded devices which are not updatable, so we'd like to leave it in until expiration in December given the limited lifetime left and risk of client issues beyond our control. That said, we'll accommodate whatever Mozilla prefers.
|
|
Assignee | |
Comment 3•3 years ago
|
||
Google Trust Services CP/CPS Review
CP v. 1.13 - https://pki.goog/repo/cp/1.13/GTS-CP-1.13.pdf
CPS v. 2.22- https://pki.goog/repo/cps/2.22/GTS-CPS.pdf
CP/CPS structured in accordance with RFC 3647 with no blank sections (MRSP § 3.3.5) (BR § 2.2)
Good
CP/CPS made available under a Creative Commons License (MRSP § 3.3.3)
“CPs and CPSes are made available to Mozilla under one of the following Creative Commons licenses (or later versions)”
OK – the only language indicates that Google owns the intellectual property rights in the CPS. (CPS § 9.5) Section 9.5 of the CP says "no stipulation".
Statement of adherence to BRs and their precedence (MRSP § 2.3) (BR § 2.2)
“The CA SHALL publicly give effect to these Requirements and represent that it will adhere to the latest published version”, including a statement such as “in the event of any inconsistency between this CP/CPS and those Requirements, those Requirements take precedence.”
Should be fixed – Section 2.2 of the CPS only states, “Google conforms to the current version of the CA/Browser Forum’s Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates published at http://www.cabforum.org.” Section 1.1 of the CP says, "In the event of any inconsistency between this document and those Requirements, the CA/Browser Forum’s Requirements take precedence over this document." These two (CP and CPS) ought to be made consistent.
Separate, EKU-constrained issuing CAs (MRSP § 5.3) (BR § 7.1.2.2.g.)
Intermediate CAs must have an EKU, not the anyEKU EKU, and not both serverAuth and an emailProtection, codesigning, or timeStamping EKU.
Good – Section 7.1.2.3.f. states, "The value anyExtendedKeyUsage MUST NOT be present."
Clear identification of CAs covered by CP/CPS (MRSP § 3.3.6)
“CAs must provide a way to clearly determine which CP and CPS applies to each of its root and intermediate certificates.”
Good – Section 1.3.1 of the CPS identifies the root and intermediate CA certificates.
Explicit annual revision of CP/CPS w/ table of changes (MRSP § 3.3.4) (BR § 2.3)
“CPs and CPSes MUST be reviewed and updated as necessary at least once every year, as required by the Baseline Requirements. CAs MUST indicate that this has happened by incrementing the version number and adding a dated changelog entry, even if no other changes are made to the document.” Also, a version history table provides evidence of compliance and good change management practices.
Good - Appendix D of the CPS contains a “Document History”. Section 2.3 of the CPS states that Google reviews and updates the CPS annually. While the CPS does not explicitly state that it does this “even if no other changes are made to the document,” a review of Appendix D indicates that the CPS has been updated and reversioned at least annually.
Statement of Non-Delegation for Domain Validation (BR § 1.3.2)
“With the exception of sections 3.2.2.4 and 3.2.2.5, the CA MAY delegate the performance of all, or any part, of Section 3.2 requirements to a Delegated Third Party, provided that the process as a whole fulfills all of the requirements of Section 3.2.”
Good – Section 1.3.2 of the CPS states, “All RA functions for the Google CAs listed in this CPS are be performed by Google.”
Clear problem reporting instructions in section 1.5.2 (BR § 4.9.3)
“The CA SHALL provide Subscribers, Relying Parties, Application Software Suppliers, and other third parties with clear instructions for reporting suspected Private Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, inappropriate conduct, or any other matter related to Certificates. The CA SHALL publicly disclose the instructions through a readily accessible online means and in section 1.5.2 of their CPS.”
Should be fixed - It is unclear which email address should be used for making a revocation request due to key compromise. One email address is for “security issues, such as vulnerability reports or external reports of key compromise” and another email address is for “a suspected Private Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, inappropriate conduct, or any other matter related to Certificates.” The instruction regarding the email subject line is good, “please add “Revocation request” and the domain name, IP address or certificate serial number into the subject line.”
Naming compliant with X.500, RFC5280 and BRs
The structure and use of names in certificates must comply with the Baseline Requirements (and EV Guidelines, if applicable), and other standards.
OK - Section 7.1.4 of the CP provides detail on naming. Section 3.1.1 of the CPS references X.501 naming.
No internal names or reserved IP addresses (BR § 7.1.4.2.1)
“CAs SHALL NOT issue certificates with a subjectAltName extension or subject:commonName field containing a Reserved IP Address or Internal Name.”
OK – While “Internal Name” is defined as “[a] string of characters (not an IP address) in a Common Name or Subject Alternative Name field of a Certificate that cannot be verified as globally unique within the public DNS at the time of certificate issuance because it does not end with a Top Level Domain registered in IANA’s Root Zone Database.” This term is not used in the CPS. Reserved IP address is not defined or used in the CPS. However, Section 7.1.4.2.1 of the CP states, " CAs SHALL NOT issue certificates with a subjectAltName extension or subject:commonName field containing a Reserved IP Address or Internal Name."
ALL certificates must meet Mozilla/BR validation requirements
CPS must specifically explain validation methods and validation steps taken to verify certificate requests in accordance with BR §§ 3.2.2.4 and 3.2.2.5 (MRSP § 2.2.3 and MRSP § 3.3.1)
CP/CPS must be sufficient “for Mozilla to determine whether and how the CA complies with this policy, including a description of the steps taken by the CA to verify certificate requests”.
[Note: It is also recommended that CAs ensure that the domain name registrant has approved or authorized a certificate request such that the certificate cannot be used to facilitate surreptitious interception by third parties (except with the domain registrant's permission).]
OK – Most details are provided in the Google CP. In the CPS, Google states that it uses domain validation methods from BR sections 3.2.2.4.7, 3.2.2.4.10, and 3.2.2.4.19. And “Where the use of the methods listed above is not feasible, Google may use the methods described in Sections 3.2.2.4.2, 3.2.2.4.15 or 3.2.2.4.16 BR as an alternative.” For IP address validation, the CPS does not specify the method(s) used – “IP address authentication is performed in accordance with the procedures set out in Section 3.2.2.5 BR.” The CP contains additional details concerning these methods which Google might want to also cross-reference for readers' benefit.
CA validates domain part of all e-mail addresses (MRSP § 2.2.2)
“For a certificate capable of being used for digitally signing or encrypting email messages, the CA takes reasonable measures to verify that the entity submitting the request controls the email account associated with the email address referenced in the certificate or has been authorized by the email account holder to act on the account holder’s behalf. The CA SHALL NOT delegate validation of the domain portion of an email address.”
Must be Fixed - Appendix C indicates that SMIME is a potential EKU. The email trust bit will be enabled, so the CPS needs to be clear about email address validation. In addition to MRSP 2.2.2, please refer to https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Email_Challenge-Response and https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Verifying_Email_Address_Control
The CP and CPS should have a section that discusses the challenge-response or other method of email address validation.
Data sources need to be accurate (BR § 3.2.2.7 and EVG § 11.11.5)
For OV – “[For a] Reliable Data Source, the CA SHALL evaluate the source for its reliability, accuracy, and resistance to alteration or falsification.”
Meh – While section 3.2.2.7 of the Google CP sets forth the evaluation criteria for determining whether a source is a "Reliable Data Source", and both the CP and CPS have a definition of Reliable Data Source, section 3.2.2.7 of the CPS asserts that "All data sources are evaluated for reliability, accuracy, and for their protection from alteration and falsification before they are used for I&A purposes." This section could be improved with a description of the practices that it uses to vet and track the reliability of data sources.
All information in a certificate must be verified (MRSP § 2.2.1)
“All information that is supplied by the certificate subscriber MUST be verified by using an independent source of information or an alternative communication channel before it is included in the certificate.”
Meh – Section 3.2.4 of the CPS states that Google does not verify the OU field or other information designated as non-verified in the certificate. Google should consider adopting language from the CA/B Forum for how it treats the OU field. Section 4.2.2 states, however, that "Google only considers Certificate applications for which all required subscriber information has been provided and validated." (Section 3.2.4 of the CP makes no stipulation.)
Data reuse (certificate renewal) limited to 825 days (MRSP § 2.1.5) (BR § 4.2.1)
CAs must “verify that all of the information that is included in SSL certificates remains current and correct at time intervals of 825 days or less”.
OK – But Google should consider amending its CP and CPS to reduce information reuse to 398 days, since that will be a new requirement to be adopted soon.
CAA record checking and recognized domain names in section 4.2 (BR § 2.2)
“Section 4.2 of a CA’s Certificate Policy and/or Certification Practice Statement SHALL state the CA’s policy or practice on processing CAA Records for Fully Qualified Domain Names; that policy shall be consistent with these Requirements.”
Good – Section 4.2.2.4 of the CPS adequately states its policy/practice for processing CAA records.
Accounts capable of certificate issuance must have multi-factor authentication (MRSP § 2.1.3)
CAs must “enforce multi-factor authentication for all accounts capable of causing certificate issuance or performing Registration Authority or Delegated Third Party functions, or implement technical controls operated by the CA to restrict certificate issuance through the account to a limited set of pre-approved domains or email addresses”.
Good – CPS Section 6.5.1 states, "CA systems enforce multi-factor authentication for all accounts capable of directly causing certificate issuance."
Pre-issuance linting (Recommended Practices)
“It is strongly recommended that CAs integrate such tools …. Because BR or RFC violations are generally considered by Mozilla to be misissuance, such integration will reduce the number of misissuance events a CA experiences”
Meh – Google should consider mentioning in the CPS that it runs certificate-checking , pre-issuance linting tools. E.g. as a new second sentence in section 4.3.1 of its CPS.
Revocation in accordance with BR section 4.9.1 (MRSP § 6.1) (BR §§ 4.9.1.1 and 4.9.1.2)
24-hour revocation for reasons (1)-(5); 5 days for reasons (1)-(11) and 7 days for Intermediate CAs reasons (1) – (9)
Should be fixed – Google should insert subsection 4 of BR 4.9.1.1 - 4. "The CA is made aware of a demonstrated or proven method that can easily compute the Subscriber’s Private Key based on the Public Key in the Certificate (such as a Debian weak key, see https://wiki.debian.org/SSLkeys);"
SMIME Reasons for Revocation (MRSP § 6.2)
“For any certificate in a hierarchy capable of being used for S/MIME, CAs MUST revoke certificates upon the occurrence of any of the following events …”
Meh – For CPS 4.9.1.1, please refer to MRSP § 6.2 (add "the CA receives notice or otherwise becomes aware of any circumstance indicating that use of the email address in the certificate is no longer legally permitted").
CRLs at least every 7 days w/ nextUpdate not more than 10 days (MRSP § 6)
Good – See CPS section 4.9.7
CA must not allow certificate suspension (BR § 4.9.13)
Good – CPS section 4.9.13 - "Google does not suspend certificates."
OCSP updates every 4 days w/ max. expiration of 10 days (MRSP § 6)
Good – See CPS section 4.9.10
Provide Mozilla notice immediately upon private CA key compromise (MRSP § 7)
“Changes that are motivated by a security concern such as certificate misissuance or a root or intermediate compromise MUST be treated as a security-sensitive, and a secure bug filed in Bugzilla.”
Good – CPS section 5.7.1 states, "Google maintains an Incident Response Plan and a Disaster Recovery Plan, which set out the procedures necessary to ensure business continuity, to notify affected stakeholders, and to reasonably protect Application Software, Suppliers, …" (extra comma should be removed).
CA must not generate Subscriber key pairs (MRSP § 5.2)
“CAs MUST NOT generate the key pairs for end-entity certificates that have an EKU extension containing the KeyPurposeIds id-kp-serverAuth or anyExtendedKeyUsage.”
OK – Section 6.1.1 of the CP states, "If the Subscriber Certificate will contain an extKeyUsage extension containing either the values id-kp-serverAuth [RFC5280] or anyExtendedKeyUsage [RFC5280], the CA SHALL NOT generate a Key Pair on behalf of a Subscriber, and SHALL NOT accept a certificate request using a Key Pair previously generated by the CA." Google should consider adding similar language to its CPS just to make it clear that it does not generate subscriber private keys for TLS server certificates.
Must meet RSA key requirements (MRSP § 5.1)
Good – CP section 6.1.5 states that " Ensure that the modulus size, in bits, is evenly divisible by 8." CPS Section 6.1.6 and Appendix B state that "the public exponent is an odd number equal to 3 or more". Other language in the CP covers other RSA key stipulations.
Must meet ECDSA key requirements, P-256 or P-384 (MRSP § 5.1)
Good – Appendix B specifies that ECDSA keys use one of the following curves: P-256 or P-384
Certificate lifetimes limited to 398 days (BR § 6.3.2)
“Subscriber Certificates … SHOULD NOT have a Validity Period greater than 397 days and MUST NOT have a Validity Period greater than 398 days.”
Good – Section 6.3.2 says, "Subscriber certificates are issued for a period of one year or less." Also, Appendix C indicates that certificates are valid for no more than 365 days. CP also contains comparable language.
Network Security (MRSP § 2.1.2)
CAs must “follow industry best practice for securing their networks, for example by conforming to the CAB Forum Network Security Guidelines or a successor document”.
Needs to be Fixed – Section 6.7 of the CPS is only a single sentence and does not reference compliance with the CA/Browser Forum's Network and Certificate System Security Requirements. (CP has no stipulation)
Serial numbers greater than 64 bits generated by a CSPRNG (MRSP § 5.2)
“all new certificates MUST have a serial number greater than zero, containing at least 64 bits of output from a CSPRNG.”
OK- The CP states, "CAs SHALL generate non‐sequential Certificate serial numbers greater than zero (0) containing at least 64 bits of output from a CSPRNG." (I could not find where this is specified in the CPS.)
EKUs required in certificates issued after 7-1-2020 (MRSP § 5.2) (BR § 7.1.2.3.f)
Good – CP section 7.1.2.3 f and Appendix C certificate profiles for OV and DV certificates both say that the EKU must include either serverAuth or clientAuth, or both.
Use of SHA-1 prohibited (MRSP § 5.1.3) (BR § 7.1.3.2.1)
Good – Covered in CP section 7.1.3.2.1
Any CN must also be in a SAN (BR § 7.1.4.2.2.a)
Good – CP section 7.1.4.2.2 covers this.
|
|
Assignee | |
Updated•3 years ago
|
Thank you for the detailed feedback, Ben. Your input is very helpful.
We will review the suggestions in detail and share updated documents shortly.
|
|
Assignee | |
Updated•3 years ago
|
The updated versions are now available at https://pki.goog/repository/.
|
|
Assignee | |
Comment 6•3 years ago
|
||
2nd Review - Based on CPS v. 3.0 dated March 25, 2021
https://pki.goog/repo/cps/3.0/GTS-CPS.pdf
https://pki.goog/repository/
Statement of adherence to BRs and their precedence (MRSP § 2.3) (BR § 2.2)
“The CA SHALL publicly give effect to these Requirements and represent that it will adhere to the latest published version”, including a statement such as “in the event of any inconsistency between this CP/CPS and those Requirements, those Requirements take precedence.”
OK - the CP states, "All CAs subject to this CP SHALL give effect to the BR in their current version and indicate their applicability in their CPS. In the event of any inconsistency between this CP and the BR, the BR takes precedence."
Clear problem reporting instructions in section 1.5.2 (BR § 4.9.3)
“The CA SHALL provide Subscribers, Relying Parties, Application Software Suppliers, and other third parties with clear instructions for reporting suspected Private Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, inappropriate conduct, or any other matter related to Certificates. The CA SHALL publicly disclose the instructions through a readily accessible online means and in section 1.5.2 of their CPS.”
Should be fixed - It is unclear which email address should be used for making a revocation request due to key compromise. One email address is for “security issues, such as vulnerability reports or external reports of key compromise” and another email address is for “a suspected Private Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, inappropriate conduct, or any other matter related to Certificates.” The instruction regarding the email subject line is good, “please add “Revocation request” and the domain name, IP address or certificate serial number into the subject line.”
OK - After editing this section it is more clear and there is now less confusion about how to contact Google.
CA validates domain part of all e-mail addresses (MRSP § 2.2.2)
“For a certificate capable of being used for digitally signing or encrypting email messages, the CA takes reasonable measures to verify that the entity submitting the request controls the email account associated with the email address referenced in the certificate or has been authorized by the email account holder to act on the account holder’s behalf. The CA SHALL NOT delegate validation of the domain portion of an email address.”
Must be Fixed - Appendix C indicates that SMIME is a potential EKU. The email trust bit will be enabled, so the CPS needs to be clear about email address validation. In addition to MRSP 2.2.2, please refer to https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Email_Challenge-Response and https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Verifying_Email_Address_Control
The CP and CPS should have a section that discusses the challenge-response or other method of email address validation.
Good - Section 3.2.2.1 now states, "For S/MIME certificates, Applicant information is validated by using one of the following:
- An email challenge/response procedure which consists of sending a Random Value to the
email address to be included in the Certificate to verify that the Applicant controls the
email address."
Other conforming changes were also made.
Data sources need to be accurate (BR § 3.2.2.7 and EVG § 11.11.5)
For OV – “[For a] Reliable Data Source, the CA SHALL evaluate the source for its reliability, accuracy, and resistance to alteration or falsification.”
Meh – While section 3.2.2.7 of the Google CP sets forth the evaluation criteria for determining whether a source is a "Reliable Data Source", and both the CP and CPS have a definition of Reliable Data Source, section 3.2.2.7 of the CPS asserts that "All data sources are evaluated for reliability, accuracy, and for their protection from alteration and falsification before they are used for I&A purposes." This section could be improved with a description of the practices that it uses to vet and track the reliability of data sources.
OK - Section 3.2.2.7 of the CPS now provides that data sources "are revalidated in accordance with the following terms.
• Legal existence and identity of Applicant - 397 days;
• Domain name - 397 days;
• Authority of Applicant - 397 days."
All information in a certificate must be verified (MRSP § 2.2.1)
“All information that is supplied by the certificate subscriber MUST be verified by using an independent source of information or an alternative communication channel before it is included in the certificate.”
Meh – Section 3.2.4 of the CPS states that Google does not verify the OU field or other information designated as non-verified in the certificate. Google should consider adopting language from the CA/B Forum for how it treats the OU field. Section 4.2.2 states, however, that "Google only considers Certificate applications for which all required subscriber information has been provided and validated." (Section 3.2.4 of the CP makes no stipulation.)
Good - Section 3.2.4 now states, "Google does not include unverified subject information in Subscriber Certificates."
Pre-issuance linting (Recommended Practices)
“It is strongly recommended that CAs integrate such tools …. Because BR or RFC violations are generally considered by Mozilla to be misissuance, such integration will reduce the number of misissuance events a CA experiences”
Meh – Google should consider mentioning in the CPS that it runs certificate-checking , pre-issuance linting tools. E.g. as a new second sentence in section 4.3.1 of its CPS.
Good - Section 4.3.1 now states "Prior to signing a Certificate Google performs conformance linting using appropriate tooling. Linting is done over the precertificate and the issued certificate. If linting reports a nonconformity, a report is generated and issuance is halted."
Revocation in accordance with BR section 4.9.1 (MRSP § 6.1) (BR §§ 4.9.1.1 and 4.9.1.2)
24-hour revocation for reasons (1)-(5); 5 days for reasons (1)-(11) and 7 days for Intermediate CAs reasons (1) – (9)
Should be fixed – Google should insert subsection 4 of BR 4.9.1.1 - 4. "The CA is made aware of a demonstrated or proven method that can easily compute the Subscriber’s Private Key based on the Public Key in the Certificate (such as a Debian weak key, see https://wiki.debian.org/SSLkeys);"
Good - Fixed
SMIME Reasons for Revocation (MRSP § 6.2)
“For any certificate in a hierarchy capable of being used for S/MIME, CAs MUST revoke certificates upon the occurrence of any of the following events …”
Meh – For CPS 4.9.1.1, please refer to MRSP § 6.2 (add "the CA receives notice or otherwise becomes aware of any circumstance indicating that use of the email address in the certificate is no longer legally permitted").
Fixed - It now states, "or email address in the Certificate is no longer legally permitted"
Network Security (MRSP § 2.1.2)
CAs must “follow industry best practice for securing their networks, for example by conforming to the CAB Forum Network Security Guidelines or a successor document”.
Needs to be Fixed – Section 6.7 of the CPS is only a single sentence and does not reference compliance with the CA/Browser Forum's Network and Certificate System Security Requirements. (CP has no stipulation)
Good - Section 6.7 now states, "Google’s certificate systems are protected by a set of controls that implement the CA/Browser Forum’s Network and Certificate System Security Requirements."
|
|
Assignee | |
Updated•3 years ago
|
|
|
Assignee | |
Updated•3 years ago
|
|
|
Assignee | |
Comment 7•3 years ago
|
||
Today I started public discussion on the replacement of 5 of the GTS roots, as found here: https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/lAu1_S48RAA/m/vVnldsU4BAAJ. I have announced a tentative date of 15-Sept-2021, on which I will close public discussion.
|
|
Assignee | |
Comment 8•3 years ago
•
|
||
Today I closed public discussion on this request and recommended approval to replace the 5 GTS roots - https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/lAu1_S48RAA/m/vhjGOlwNCgAJ The 7-day period runs through 9/23/2021.
|
||
Comment 9•3 years ago
|
||
Ben, please confirm that the Email trust bit is to be added to this version of the GTS root certificates. Note that the previous version of the GTS root certificates only had the Websites trust bit enabled. And I am not finding mention of the trust bit addition in the discussion thread (if it's there, please point me to it).
** GlobalSign (Email, Websites) -- this root did have both trust bits enabled
** GTS Root R1 (Email, Websites) -- this and the following roots only had the Websites trust bit enabled
** GTS Root R2 (Email, Websites)
** GTS Root R3 (Email, Websites)
** GTS Root R4 (Email, Websites)
|
|
Assignee | |
Comment 10•3 years ago
|
||
In the CCADB, GTS and I had it marked to enable it with the email trust bit. That must have been missed when we conducted the public discussion. Should I send out a public-discussion follow-up to the MDSP list?
|
|
||
Comment 11•3 years ago
|
||
(In reply to Ben Wilson from comment #10)
In the CCADB, GTS and I had it marked to enable it with the email trust bit. That must have been missed when we conducted the public discussion. Should I send out a public-discussion follow-up to the MDSP list?
Yes. Please confirm with GTS if they really do want the email trust bit enabled on all of the roots as well. If they do, then please follow up in the discussion thread to make it clear that the email trust bit is to be enabled too, and give an opportunity for feedback.
|
||
Comment 12•3 years ago
|
||
Yes, Google Trust Services intends to issue S/MIME certificates and was intending that this update included the associated permission update.
|
|
Assignee | |
Comment 13•3 years ago
|
||
I re-opened discussion on this issue, which closed a a few days ago, and received no opposition. See https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/lAu1_S48RAA/m/MmIlNpwuCAAJ
I believe we can move forward with enabling the email trust bit as indicated in the CCADB.
|
|
||
Comment 14•3 years ago
|
||
As per Comments #8 and #13, and on behalf of Mozilla I approve this request from Google Trust Services LLC to include the following root certificates:
** GlobalSign (Email, Websites)
** GTS Root R1 (Email, Websites)
** GTS Root R2 (Email, Websites)
** GTS Root R3 (Email, Websites)
** GTS Root R4 (Email, Websites)
I will file the NSS bug for the approved changes.
|
|
||
Comment 15•3 years ago
|
||
I have filed bug #1735407 against NSS for the actual changes.
|
|
||
Updated•2 years ago
|
|
||
Updated•2 years ago
|
Description
•