contents

Google Trust Services, TLS CP/CPS v.6.0

1. INTRODUCTION

1.1. Overview

This document is the combined Certificate Policy and Certification Practice Statement for TLS server Certificates ("CP/CPS") of Google Trust Services ("GTS") for the GTS Public Key Infrastructure ("GTS PKI"). It defines a set of business, technical and legal requirements for the issuance and management of publicly-trusted Certificates within the GTS PKI. In addition, it describes the practices GTS has adopted to meet these requirements.

The GTS PKI has been established to enable reliable and secure identity verification, and to facilitate the preservation of confidentiality and integrity of data in electronic transactions. GTS PKI services include, but are not limited to, approving, issuing, managing, using, revoking and renewing publicly-trusted Certificates in a manner consistent with this CP/CPS. The certificates are issued by or on behalf of Google Trust Services Europe Ltd for Subscribers in the EU and by Google Trust Services LLC for all other Subscribers.

GTS conforms to the latest version of the CA/Browser Forum (CABF) Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates (BR) published at https://www.cabforum.org. In the event of any inconsistency between the requirements in this CP/CPS and the CABF Baseline Requirements, the applicable CABF Baseline Requirements take precedence.

GTS requires its affiliated entities, Applicants, Subscribers, and Relying Parties who are involved in issuing and managing digital Certificate within the GTS PKI hierarchy to adhere to this CP/CPS. Other important documents that accompany this CP/CPS include the associated Subscriber and Relying Party Agreements. Further information related to the policies and issuance practices of GTS can be found at https://pki.goog/.

This CP/CPS is structured in accordance with the Internet Engineering Task Force (IETF) standard RFC 3647.

This CP/CPS is licensed under the Creative Commons Attribution 4.0 International License. To view a copy of this license, visit https://creativecommons.org/licenses/by/4.0/ or send a letter to Creative Commons, PO Box 1866, Mountain View, CA 94042, USA.

1.2. Document name and identification

This document is the GTS CP/CPS for publicly trusted Certificates. It has been approved for publication by the GTS Policy Authority.

The OID arc for Google Trust Services is {iso(1) iso-identified-organization(3) dod(6) internet(1) private(4) enterprise(1) google(11129) 2(2) 5(5) 3(3)} (1.3.6.1.4.1.11129.2.5.3). See section 7.1.6 for a list of Certificate Policy object identifiers used by GTS.

See Appendix B for a list of revisions to this document.

1.3. PKI participants

1.3.1. Certification authorities

See definition of "Certification Authority" in Appendix A Definitions.

All certificates in the GTS PKI are issued by GTS.

This CP/CPS applies to all Certificates issued and signed by the following CAs hereinafter referred to as "GTS CAs".

Root CAs

Prior to August 11, 2016, GTS Root R1, GTS Root R2, GTS Root R3, GTS Root R4, and GlobalSign R2 and R4 were operated by GMO GlobalSign, Inc. according to GMO GlobalSign, Inc.'s Certificate Policy and Certification Practice Statement. Between August 11, 2016 and December 8, 2016, Google Inc. operated these Roots according to Google Inc.'s Certification Practice Statement. As of December 9, 2016, Google Trust Services LLC operates these Roots under this CP/CPS.

The CA Certificates of the above listed CAs can be retrieved at https://pki.goog/repository/.

Cross-signed Root CAs

The CA Certificates of the above listed CAs can be retrieved at https://pki.goog/repository/.

Intermediate CAs

The CA Certificates of the above listed CAs can be retrieved at https://pki.goog/repository/.

Externally Operated Subordinate CAs

The following (only non-revoked and non-expired) externally operated subordinate CAs have a GTS CA listed as the issuer of their CA Certificate.

Private CAs, not disclosed to Root Programs

1.3.2. Registration authorities

See definition of "Registration Authority" in Appendix A Definitions.

All RA functions for the GTS CAs listed in this CP/CPS are performed by GTS or are within the scope of GTS's WebTrust audit.

1.3.3. Subscribers

See definition of "Subscriber" in Appendix A Definitions.

All Subscribers are required to enter into the Subscriber Agreement available in the repository at https://pki.goog/repository.

1.3.4. Relying parties

See definition of "Relying Party" in Appendix A Definitions.

1.3.5. Other participants

Third-party CAs who cross-sign root or subordinate CAs for the GTS PKI.

1.4. Certificate usage

1.4.1. Appropriate certificate uses

Appropriate Certificate uses under this CP/CPS are all uses for the purpose of authentication using digital signatures, encryption and access control which are consistent with the key usage extension fields of the respective Certificate and are not in violation of this CP/CPS, applicable law, or any agreement made between the Subscriber and GTS.

1.4.2. Prohibited certificate uses

Certificates are not proof of the trustworthiness or honesty of the Subscriber nor do they indicate the Subscriber's compliance with any law. By issuing a certificate GTS merely confirms that it has used reasonable means to verify the information in the certificate before it was issued.

Certificates issued under this CP/CPS are not intended and may not be used for any application requiring fail-safe performance such as (a) the operation of nuclear power facilities, (b) air traffic control systems, (c) aircraft navigation systems, (d) weapons control systems, or (e) any other system whose failure could lead to injury, death or environmental damage.

GTS Certificates may not be used for man-in-the middle purposes or where their usage is prohibited by law.

1.5. Policy administration

1.5.1. Organization administering the document

The GTS CA Policy Authority is responsible for the drafting, maintenance, and interpretation of this CP/CPS.

1.5.2. Contact person

Google Trust Services LLC
1600 Amphitheatre Parkway
Mountain View, CA 94043
USA

Google Trust Services Europe Ltd
70 SIR JOHN ROGERSON'S QUAY
DUBLIN, D02R296
Ireland

Subscribers, Relying Parties, Application Software Suppliers, and other third parties may contact us concerning service outages, security issues or any other matter related to Certificates by using the contact form at https://pki.goog/contact/.

Certificate Problem Reports and other requests for Certificate revocation e.g. due to suspected Private Key compromises, Certificate misuse, or other types of fraud, compromise, misuse or inappropriate conduct must be submitted following the process and instructions described in Section 4.9.3 of this CP/CPS.

1.5.3. Person determining CP/CPS suitability for the policy

The GTS CA Policy Authority determines the suitability and applicability of this CP/CPS.

1.5.4. CP/CPS approval procedures

GTS may modify this CP/CPS at any time by posting a revised version in the Repository (https://pki.goog/repository/). New CP/CPS versions are approved by the GTS CA Policy Authority and become effective upon posting.

1.6. Definitions and acronyms

1.6.1. Definitions

See Appendix A.

1.6.2. Acronyms

See Appendix A.

1.6.3. References

See Appendix A.

1.6.4. Conventions

By convention, this CP/CPS omits time and timezones when listing effective requirements such as dates. Except when explicitly specified, the associated time with a date shall be 00:00:00 UTC.

2. PUBLICATION AND REPOSITORY RESPONSIBILITIES

2.1. Repositories

GTS maintains a Repository on its website at https://pki.goog/repository/ which comprises:

  1. Its publicly trusted Root Certificates, non-constrained Subordinate CA Certificates and cross-certified CA Certificates.
  2. Current and past versions of its CP/CPS, Subscriber Agreements, and Relying Party Agreements.

GTS CA Certificates and Subscriber Certificates contain URLs to locations where Certificate-related information is published.

When applicable, GTS makes the CRLs and OCSP services for its CAs publicly available online and reachable 24 hours a day, 7 days a week. Revocation services are designed to minimize downtime. CRLs signed by intermediate CAs are provided in a partitioned format to maintain a maximum CRL shard size of ~10MB for all CRLs.

2.2. Publication of information

This CP/CPS is available in the repository at https://pki.goog/repository.

Web pages for Application Software Suppliers to test their software with Subscriber Certificates that chain up to each publicly trusted Root Certificate are listed at https://pki.goog/repository/.

2.3. Time or frequency of publication

CA Certificates are published as soon as possible prior to their usage for issuing to Subscribers. This typically means within seven (7) days of creation.

Updates to this CP/CPS, the Subscriber Agreement and the Relying Party Agreement located at https://pki.goog/repository/ are published as soon as possible. This typically means within seven (7) days of receipt or approval. GTS reviews and updates this CP/CPS at least once every 365 days.

CRLs are published in accordance with Section 4.9.7. OCSP response updates are published in accordance with Section 4.9.9.

2.4. Access controls on repositories

The Repository is publicly available. GTS operates physical and logical security controls to protect the Repository from unauthorized modification or deletion.

3. IDENTIFICATION AND AUTHENTICATION

3.1. Naming

3.1.1. Types of names

See Section 7.1 for the types of names which may appear in GTS Certificates.

3.1.2. Need for names to be meaningful

No stipulation.

3.1.3. Anonymity or pseudonymity of subscribers

Subscribers are not permitted to include pseudonyms in the subject information of their Certificate applications.

3.1.4. Rules for interpreting various name forms

GTS may issue Certificates for Internationalized Domain Names (IDNs). GTS may perform checks to detect the use of IDNs in homoglyph impersonation attacks.

GTS does not make any assertions about the reliability or validity of website content.

3.1.5. Uniqueness of names

No stipulation.

3.1.6. Recognition, authentication, and role of trademarks

Applicants are prohibited from requesting certificates that contain content that infringes on the intellectual property and commercial rights of others. GTS does not determine whether Applicants have intellectual property rights in the name used in a Certificate Application nor does GTS resolve any dispute concerning the ownership of a domain name or trademark. GTS may reject any Certificate Application and revoke any Certificate because of such a dispute.

3.2. Initial identity validation

3.2.1. Method to prove possession of private key

Applicants must prove ownership of a private key by providing a PKCS #10 compliant Certificate Signing Request, or a cryptographically equivalent proof.

3.2.2. Authentication of organization and domain identity

If the countryName attribute of the subject is present, then GTS verifies the country associated with the Subject using at least one of the following:

  1. A government agency in the jurisdiction of the Applicant's legal creation, existence, or recognition;
  2. A third party database that is periodically updated and considered a Reliable Data Source;
  3. A site visit by GTS or a third party who is acting as an agent for GTS;
  4. A utility bill, bank statement, credit card statement, government-issued tax document, or other form of identification that GTS determines to be reliable.

Prior to issuing a subscriber Certificate, GTS validates that the Applicant has control using the following approved methods as defined in the BR at the time of validation:

In addition, GTS may supplement its validation procedure with checks against internal data sources.

GTS does not issue Certificates for FQDNs that contain "onion" as the rightmost Domain Label.

3.2.3. Authentication of individual identity

Not applicable. GTS does not issue individually validated certificates to natural persons.

3.2.4. Non-verified subscriber information

Not applicable. GTS does not include unverified subject information in Certificates.

3.2.5. Validation of authority

GTS uses a reliable method of communication with the Applicant or its representative.

The authority of Applicants to request Certificates on behalf of an organization is verified during the validation of the Applicant's identity.

GTS does not issue Organization Validated (OV) subscriber certificates for TLS.

3.2.6. Criteria for interoperation

All Cross-Certified Subordinate CA Certificates that identify a GTS CA as the Subject are listed in the Repository, provided that GTS has arranged for or accepted the establishment of the trust relationship.

3.3. Identification and authentication for re-key requests

3.3.1. Identification and authentication for routine re-key

See Section 4.7.

3.3.2. Identification and authentication for re-key after revocation

See Section 4.7.

3.4. Identification and authentication for revocation request

Identification & authentication for revocation requests are detailed under Section 4.9 of this document.

Identification and authentication procedures are not required in cases where the revocation request is made by GTS or where the request is made by reference to a revocation reason that is independent of the requestor's identity.

4. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS

4.1. Certificate application

4.1.1. Who can submit a certificate application

Certificate applications can be submitted through the GTS ACME API or through products and services that integrate with the GTS ACME API and offer certificate request or management functions.

In accordance with Section 5.5.2, GTS maintains an internal database of all previously revoked Certificates and previously rejected Certificate requests due to suspected phishing or other fraudulent usage or concerns. GTS uses this information to identify subsequent suspicious Certificate requests.

4.1.2. Enrollment process and responsibilities

Applicants can enroll by registering an ACME account using the GTS ACME API.

To obtain a Certificate, applicants must submit a certificate application containing the information below. For most Certificates, this application consists of the Applicant's ACME Certificate request.

By executing the Subscriber Agreement, the Applicant warrants that the information included in the Certificate request is correct.

4.2. Certificate application processing

GTS performs the applicable Certificate validation procedures and verifies the completeness, accuracy and authenticity of the information provided by the Applicant prior to issuing a Certificate. The procedures include:

4.2.1. Performing identification and authentication functions

GTS performs identification and authentication functions during the certificate application process.

Certificate applications are not approved unless GTS has obtained all necessary information as specified in Section 4.1.2. If missing information cannot be readily obtained from a trusted internal data source, GTS may ask the Applicant to provide the required information in an alternative form.

Completed validations and supporting evidence may be re-used for up to 398 days prior to issuing the Certificate.

GTS maintains procedures to identify high risk Certificate requests that require additional verification activity prior to their approval. This includes maintaining an internal database of all Certificates that have previously been revoked and all Certificate requests that have been rejected by GTS. This information is used during identification and authentication to identify suspicious Certificate requests.

4.2.1.1. Certificate authority authorization

GTS checks for CAA records for each dNSName in the subjectAltName extension of the Certificate to be issued and follows the processing instructions as specified in RFC 8659 and Section 3.2.2.8 of the TLS BRs. GTS acts in accordance with CAA records if present.

The following Issuer Domain Name in CAA "issue" or "issuewild" records permits GTS to issue:

If GTS issues a certificate, it does so within the TTL of the CAA record, or 8 hours, whichever is greater.

A Certificate is not issued if an unrecognized property has the critical flag set.

GTS may decide not to check for a CAA record for certificates for which a Certificate Transparency precertificate was created and logged in at least two public logs, and for which CAA was checked.

Lookup failures during CAA checking are not considered permission to issue.

GTS may decide to check for the existence of specific CAA parameters depending on the policy of the certificate that will be issued.

GTS may choose to limit issuance according to RFC 8657.

4.2.2. Approval or rejection of certificate applications

GTS may elect not to issue any certificate at its discretion.

GTS only accepts Certificate applications for which all required subscriber information has been provided and validated. All other applications are rejected.

Certificate applications that contain a new gTLD are not approved while the gTLD is still under consideration by ICANN.

Applications for subordinate CAs are not approved unless the CA in question will be operated by GTS or an Affiliate and will be governed by this CP/CPS.

GTS does not issue Certificates for internal names or reserved IP addresses.

4.2.3. Time to process certificate applications

No stipulation.

4.3. Certificate issuance

4.3.1. CA actions during certificate issuance

Certificate issuance from a Root CA requires at least two authorized individuals one of whom deliberately issues a direct command in order to perform the signing operation.

Subscriber leaf certificates are processed in an automated fashion using the ACME standard.

Prior to signing a Certificate, GTS 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.

GTS uses Linting tools that have been widely adopted by the industry - https://cabforum.org/resources/tools/.

4.3.2. Notification to subscriber by the CA of issuance of certificate

The issued Certificate is delivered via ACME as soon as possible.

4.4. Certificate acceptance

4.4.1. Conduct constituting certificate acceptance

The Subscriber indicates acceptance of a certificate by downloading it from the ACME provided location.

By accepting a certificate, the Subscriber agrees to be bound by the continuing responsibilities, obligations and duties imposed by the Subscriber Agreement and this CP/CPS.

4.4.2. Publication of the certificate by the CA

All Subscriber certificates are made available to Subscribers via ACME. They are also submitted to Certificate Transparency logs following typical root program requirements.

GTS does not guarantee issuance of a final certificate for every precertificate.

4.4.3. Notification of certificate issuance by the CA to other entities

See Section 4.4.2 above.

4.5. Key pair and certificate usage

4.5.1. Subscriber private key and certificate usage

No stipulation.

4.5.2. Relying party public key and certificate usage

No stipulation.

4.6. Certificate renewal

4.6.1. Circumstance for certificate renewal

Certificate renewal is the process whereby a new certificate with an updated validity period is created for an existing Key Pair.

GTS does not offer Certificate renewal. To obtain a new certificate after a GTS issued Certificate has expired, the Applicant is asked to generate a new Key Pair and request a new certificate in accordance with this CP/CPS.

4.6.2. Who may request renewal

Not applicable. See Section 4.6.1.

4.6.3. Processing certificate renewal requests

Not applicable. See Section 4.6.1.

4.6.4. Notification of new certificate issuance to subscriber

Not applicable. See Section 4.6.1.

4.6.5. Conduct constituting acceptance of a renewal certificate

Not applicable. See Section 4.6.1.

4.6.6. Publication of the renewal certificate by the CA

Not applicable. See Section 4.6.1.

4.6.7. Notification of certificate issuance by the CA to other entities

Not applicable. See Section 4.6.1.

4.7. Certificate re-key

4.7.1. Circumstance for certificate re-key

GTS treats Certificate re-key requests as requests for the issuance of a new Certificate.

4.7.2. Who may request certification of a new public key

Not applicable. See Section 4.7.1.

4.7.3. Processing certificate re-keying requests

Not applicable. See Section 4.7.1.

4.7.4. Notification of new certificate issuance to subscriber

Not applicable. See Section 4.7.1.

4.7.5. Conduct constituting acceptance of a re-keyed certificate

Not applicable. See Section 4.7.1.

4.7.6. Publication of the re-keyed certificate by the CA

Not applicable. See Section 4.7.1.

4.7.7. Notification of certificate issuance by the CA to other entities

Not applicable. See Section 4.7.1.

4.8. Certificate modification

GTS does not modify previously issued subscriber Certificates. Any request for Certificate modification will be treated as a request for the issuance of a new certificate.

4.8.1. Circumstance for certificate modification

Not applicable. See Section 4.8.

4.8.2. Who may request certificate modification

Not applicable. See Section 4.8.

4.8.3. Processing certificate modification requests

Not applicable. See Section 4.8.

4.8.4. Notification of new certificate issuance to subscriber

Not applicable. See Section 4.8.

4.8.5. Conduct constituting acceptance of modified certificate

Not applicable. See Section 4.8.

4.8.6. Publication of the modified certificate by the CA

Not applicable. See Section 4.8.

4.8.7. Notification of certificate issuance by the CA to other entities

Not applicable. See Section 4.8.

4.9. Certificate revocation and suspension

GTS supports Certificate revocation. Certificate suspension is not supported.

Certificates are revoked by adding their serial number to the appropriate CRL. If the revoked certificates reference an OCSP URL, their status is also set to revoked by the OCSP responder.

To optimise CRL service performance, GTS uses partitioned CRLs and includes appropriate CRL Distribution Point into the respective certificate.

Certificates that have expired are not revoked.

4.9.1. Circumstances for revocation

GTS follows Sections 4.9.1.1 and 4.9.1.2 of the CABF TLS Baseline Requirements when revoking certificates.

4.9.2. Who can request revocation

Certificate revocation can be requested by:

4.9.3. Procedure for revocation request

GTS maintains capabilities to receive Certificate revocation requests 24/7.

Revocation requests can be made over the ACME API in the following cases:

Revocation requests made by the Subscriber must be submitted using the appropriate GTS ACME API.

All other revocation requests must be submitted in English using the contact form available at http://pki.goog/.

Information on how to select revocation reason codes is provided in Section 4.9.1.1 of the CABF TLS Baseline Requirements.

The revocationDate field of a CRL may be backdated to enter keyCompromise as the CRLReason in the reasonCode extension. In these cases, the revocationDate field is set to the date when the certificate is first considered to be compromised.

Where deemed appropriate, GTS may also forward the case to law enforcement.

4.9.4. Revocation request grace period

GTS does not typically grant revocation grace periods. Only in exceptional circumstances will a grace period be considered.

4.9.5. Time within which CA must process the revocation request

Within 24 hours after receiving a Certificate Problem Report, GTS will investigate the facts and circumstances related to a Certificate Problem Report and provide a preliminary report on its findings to both the Subscriber and the entity who filed the Certificate Problem Report.

If revocation is needed, it is done following the CABF TLS Baseline Requirements Sections 4.9.1.1 and 4.9.1.2.

4.9.6. Revocation checking requirement for relying parties

Relying Parties are encouraged to confirm the validity of each Certificate in the certificate chain by checking the applicable CRL and/or OCSP responder before relying on a GTS Certificate.

4.9.7. CRL issuance frequency

GTS updates and issues new CRLs as specified by the CABF TLS Baseline Requirements.

4.9.8. Maximum latency for CRLs (if applicable)

No stipulation.

4.9.9. On-line revocation/status checking availability

GTS may provide revocation information via OCSP for active certificates. At its discretion, GTS may not provide OCSP when it is not required.

4.9.10 On-line revocation checking requirements

No stipulation.

4.9.11. Other forms of revocation advertisements available

Not applicable. GTS does not provide other forms of revocation advertisements.

In case of a compromise of the Subscriber's Private Key, the Subscriber must immediately notify GTS of the Private Key compromise event. GTS will revoke the concerned certificate, and publish a CRL to inform Relying Parties that the certificate can no longer be trusted.

The Subscriber is responsible for investigating the circumstances of any such compromise.

The acceptable methods that can be used by third parties as proof of key compromise are the following:

  1. Confirming the third party's possession of the Private Key by performing the procedure described in Section 7.6 of RFC 8555 and signing the revocation request with the compromised Private Key.
  2. Confirming the third party's possession of the Private Key by signing a challenge provided by GTS using the compromised Private Key.
  3. Submitting the Private Key itself.

4.9.13. Circumstances for suspension

Not applicable. GTS does not suspend Certificates.

4.9.14. Who can request suspension

Not applicable. GTS does not suspend Certificates.

4.9.15. Procedure for suspension request

Not applicable. GTS does not suspend Certificates.

4.9.16. Limits on suspension period

Not applicable. GTS does not suspend Certificates.

4.10. Certificate status services

4.10.1. Operational characteristics

Revocation entries on a CRL or OCSP responses are not removed until after the expiry date of the revoked certificate.

4.10.2. Service availability

GTS operates and maintains its CRL and OCSP services (when applicable) with resources sufficient to provide a response time of ten seconds or less under normal operating conditions.

Certificate status services are available 24x7, unless temporarily unavailable due to maintenance or service failure. Additionally, GTS maintains 24x7 ability to respond to valid Certificate Problem Reports.

4.10.3. Optional features

No stipulation.

4.11. End of subscription

A subscriber's subscription ends when its certificate expires or when the Certificate is revoked. A subscription also ends when the applicable Subscriber Agreement expires and is not renewed.

4.12. Key escrow and recovery

4.12.1. Key escrow and recovery policy and practices

Not applicable. GTS does not escrow Private Keys.

4.12.2. Session key encapsulation and recovery policy and practices

Not applicable. GTS does not support session key encapsulation or recovery.

5. FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS

5.1. Physical Security Controls

The GTS CA infrastructure is located in and operated from secure GTS facilities. Detailed security procedures are in place and followed that prohibit unauthorized access and entry into the areas of the facilities in which CA systems reside.

5.1.1. Site location and construction

GTS CA systems are located in a selected set of locations which have been evaluated for their physical security, as well as local legal considerations that may affect CA operations.

All CA systems are operated from buildings which are solidly constructed to prevent unauthorized entry.

5.1.2. Physical access

GTS has implemented appropriate physical security controls to restrict access to all hardware used for providing CA Services. Access to such hardware is limited to those personnel performing in a trusted role as described in Section 5.2.1. Access is controlled through the use of electronic access controls, mechanical combination lock sets, deadbolts, or other security mechanisms. Such access controls are manually or electronically monitored for unauthorized intrusion at all times. Only authorized personnel are allowed access, either physical or logical, to GTS systems.

GTS enforces two-person access for all physical access to CA systems.

The GTS CA servers are located inside of a locked server room. Access to the server room is controlled by badge readers with time-bound clearances, only granting entry to specific individuals during designated time frames. The private keys for the CAs are stored in hardware security modules (HSMs) that are validated to FIPS 140-2 Level 3 or higher and that are physically tamper-evident and tamper-resistant.

5.1.3. Power and air conditioning

GTS CA facilities are connected to a UPS system and emergency power generator. They are equipped with cooling systems to ensure reliable operations.

5.1.4. Water exposures

All GTS CA facilities are equipped with controls to protect CA systems from damage resulting from water leakage.

5.1.5. Fire prevention and protection

All GTS CA facilities are equipped with fire detection alarms and protection equipment.

5.1.6. Media storage

No stipulation.

5.1.7. Waste disposal

GTS takes reasonable steps to ensure that all media used for the storage of information such as keys, activation data or its files are sanitized or destroyed before they are released for disposal.

5.1.8. Off-site backup

GTS maintains multiple facilities for its CA infrastructure which also hold copies of the CA private keys for redundancy. All facilities have security controls which are equivalent across locations.

5.2. Procedural controls

5.2.1. Trusted roles

All personnel who have access to or control over cryptographic operations of a GTS CA that affect the issuance, use, and management of Certificates are considered as serving in a trusted role ("Trusted Role"). Such personnel include, but are not limited to, members of Google's Information Security Team.

5.2.2. Number of persons required per task

CA Private Keys can only be backed up, stored, and recovered by personnel in trusted roles using, at least, dual control in a physically secured environment.

5.2.3. Identification and authentication for each role

All personnel are vetted prior to appointing them to a Trusted Role and anyone performing in a Trusted Role must authenticate themselves before accessing CA systems or confidential information.

5.2.4. Roles requiring separation of duties

Audits of GTS infrastructure and Certificate issuance are performed by individuals who are independent from operators who approve Certificate issuance.

To review their conformance with applicable policies and other requirements, GTS CAs undergo annual audits performed by a Qualified Auditor.

5.3. Personnel controls

5.3.1. Qualifications, experience, and clearance requirements

GTS has implemented policies to verify the identity and trustworthiness of its personnel. Furthermore, GTS evaluates the performance of its CA personnel to ensure that they perform their duties in a satisfactory manner.

5.3.2. Background check procedures

GTS follows formal processes for selecting personnel and for performing background checks on individuals who operate GTS CAs.

5.3.3. Training requirements and procedures

All personnel who perform information verification duties receive skills-training that covers basic Public Key Infrastructure knowledge, identification and authentication procedures (including this CP/CPS), common threats to the information verification process including phishing and other social engineering attacks.

The skills-training is provided before personnel commence their role and GTS requires them to pass an examination. GTS maintains records of these trainings and ensures that personnel maintain an appropriate skill level.

5.3.4. Retraining frequency and requirements

GTS requires personnel in Trusted Roles to maintain skill levels consistent with formal training and performance management requirements and to undergo re-training at least annually.

5.3.5. Job rotation frequency and sequence

No stipulation.

5.3.6. Sanctions for unauthorized actions

GTS takes appropriate action to protect the security of its CAs. Where appropriate, this can include the suspension and termination of employees in Trusted Roles if they performed unauthorized acts, abused their authority or otherwise failed to comply with GTS policy.

5.3.7. Independent Contractor Controls

Independent contractors must meet the same training requirements as GTS employees working in the same role. Identification and authentication functions are not performed by independent contractors.

5.3.8. Documentation supplied to personnel

Training and documentation is provided to GTS employees as necessary for them to perform competently in their job role.

5.4. Audit logging procedures

5.4.1. Types of events recorded

Audit logs are generated for all events related to the security (physical and logical) and services of the CA. Logs are automatically generated whenever possible. Where this is not possible, manual logging and record keeping methods may be used. All security audit logs, both electronic and non-electronic, are retained and made available during compliance audits.

At a minimum, each audit record includes:

5.4.2. Frequency of processing log

Audit logs are reviewed on an as-needed basis.

5.4.3. Retention period for audit log

Audit logs are retained for at least the period required by Section 5.4.3 of the CABF TLS Baseline Requirements.

5.4.4. Protection of audit log

Multiple copies of audit logs are stored in different locations and protected by appropriate physical and logical access controls.

5.4.5. Audit log backup procedures

GTS maintains formal procedures to ensure that audit logs are backed up and retained to keep them available as necessary for the CA service and as stipulated by applicable requirements.

5.4.6. Audit collection system (internal vs. external)

No stipulation.

5.4.7. Notification to event-causing subject

No stipulation.

5.4.8. Vulnerability assessments

System vulnerabilities are managed in accordance with a formal process that addresses the identification, review, response, and remediation of vulnerabilities.

Additionally, GTS performs vulnerability assessments on an annual basis and after significant infrastructure or software changes.

On an annual basis, GTS performs a Risk Assessment that:

  1. Identifies foreseeable internal and external threats that could result in unauthorized access, disclosure, misuse, alteration, or destruction of any Certificate Data or Certificate Management Processes;
  2. Assesses the likelihood and potential damage caused by these threats, taking into consideration the sensitivity of the Certificate Data and Certificate Management Processes; and
  3. Assesses the adequacy of the policies, procedures, information systems, technology, and other arrangements that GTS has in place to counter such threats.

System vulnerabilities are managed in accordance with a formal process that addresses the identification, review, response, and remediation of vulnerabilities.

Additionally, GTS performs a Vulnerability Scan on public and private IP addresses belonging to the Certificate Systems on the following occasions:

GTS performs a comprehensive security review on its Certificate Systems at least once per year. Security reviews are iterative in nature and may include Code Review, Architecture Review, Configuration Review, Threat Modeling, and Penetration Testing depending on what changes occur between reviews.

GTS may perform additional reviews after infrastructure or application upgrades or modifications that it determines are significant.

5.5. Records archival

5.5.1. Types of records archived

Records to be archived are those specified in Section 5.4.1.

5.5.2. Retention period for archive

Archived records are retained for at least the period required by Section 5.5.2 of the CABF TLS Baseline Requirements.

Key generation ceremony scripts and associated records are retained at least for the lifetime of the generated key pairs.

GTS may archive log data and documentation for longer e.g. if it is necessary for security or audit reasons or if it is required by law.

5.5.3. Protection of archive

Archived information is stored at multiple physical locations to protect it from loss.

5.5.4. Archive backup procedures

Backup and recovery procedures exist to ensure that archived information can be restored if it has been lost or destroyed in one storage location.

5.5.5. Requirements for time-stamping of records

Archived records such as log files are time-stamped by the CA systems which generate them. Time-stamps need not be cryptography-based.

5.5.6. Archive collection system (internal or external)

No stipulation.

5.5.7. Procedures to obtain and verify archive information

No stipulation.

5.6. Key changeover

The procedure for providing a new CA Certificate to a Subject following a re-key is the same as the procedure for initially providing the CA Certificate.

5.7. Compromise and disaster recovery

5.7.1. Incident and compromise handling procedures

The GTS CA infrastructure is operated from redundant production sites. If a disaster causes an outage at one site, the CA service can be provided from an alternate location.

GTS 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, Subscribers, and Relying Parties in the event of a disaster, security compromise, or business failure. GTS annually tests, reviews, and updates its business continuity plan and its security plans and makes them available to its Qualified Auditor upon request.

5.7.2. Recovery procedures if computing resources, software, and/or data are corrupted

Redundant CA sites are physically separated. If software or data at one site is corrupted, it can be restored from an alternate site via a secure connection.

Backups of all relevant software and data are made on a regular basis. They are stored off-site and can be retrieved electronically when necessary.

5.7.3. Recovery procedures after key compromise

In the event that the Private Key of a GTS CA is compromised, GTS will:

Once the compromised key material has been replaced and a secure operation of the CA in question has been established, GTS may re-issue the revoked certificates following the procedure for initially providing the certificates.

5.7.4. Business continuity capabilities after a disaster

GTS employs and contracts security personnel who will use all reasonable means to monitor the CA facility after a natural or other type of disaster so as to protect sensitive materials and information against loss, additional damage, and theft.

To confirm that it possesses appropriate disaster recovery capabilities, GTS performs periodic tests of its business continuity and disaster recovery plans.

5.8. CA or RA termination

When it is necessary to terminate operation a GTS CA, the impact of the termination is minimized as much as possible in light of the prevailing circumstances. This includes:

If commercially reasonable, prior notice of the termination of a GTS CA will be given at least 3 months before the termination date.

6. TECHNICAL SECURITY CONTROLS

6.1. Key Pair generation and installation

6.1.1. Key Pair generation

Key pairs for GTS CAs are generated on hardware security modules that meet the requirements of section 6.2.1. They are generated during a ceremony that meets the requirements of this CP/CPS.

Subscriber key pairs are generated by the Subscriber.

6.1.2. Private Key delivery to subscriber

GTS never generates or has access to Subscriber Private Keys.

6.1.3. Public Key delivery to certificate issuer

Subscribers may provide their Public Key to GTS for certification via ACME.

6.1.4. CA Public Key delivery to relying parties

The Public Keys of GTS CAs are made available from the online Repository at https://pki.goog/repository/. Additionally, the Public Keys of GTS root CAs are delivered through their inclusion into the root stores of software, operating systems, and equipment manufacturers.

6.1.5. Key sizes

GTS Root CA key pairs are either RSA keys whose encoded modulus size is 4096 bits, or ECDSA keys which are a valid point on the NIST P-384 or P-256 elliptic curve.

GTS Subordinate CA key pairs are either RSA keys whose encoded modulus size is 2048 bits, or ECDSA keys which are a valid point on the NIST P-384 or P-256 elliptic curve.

The following algorithms and key lengths are permissible for subscriber certificates:

Type Permissible values
RSA 2048, 3072, 4096
ECDSA NIST P-256, P-384

6.1.6. Public Key parameters generation and quality checking

The following additional requirements apply to RSA keys:

  1. the public exponent must be an odd number equal to 3 or more,
  2. the public exponent is in the range between 2^16 + 1 and 2^256 - 1,
  3. the modulus is an odd number,
  4. the modulus is not the power of a prime, and
  5. the modulus has no factors smaller than 752.

The validity of all ECDSA keys is confirmed using either the ECC Full Public Key Validation Routine or the ECC Partial Public Key Validation Routine.

6.1.7. Key usage purposes (as per X.509 v3. key usage field)

See Section 7, Certificate Profiles.

6.2. Private Key protection and cryptographic module engineering controls

GTS implements physical and logical safeguards to prevent unauthorized Certificate issuance. Protection of the Private Key outside the validated system or device specified in Section 6.2.7 consists of physical security, encryption, or a combination of both, implemented in a manner that prevents disclosure of the Private Key.

GTS encrypts its Private Keys with an algorithm and key-length that, according to the state of the art, are capable of withstanding cryptanalytic attacks for the residual life of the encrypted key or key part.

6.2.1. Cryptographic module standards and controls

All CA Private Keys used to sign certificates, CRLs, or any related information leverage hardware security modules meeting FIPS 140-2 Level 3 or higher or Common Criteria EAL4+ security specifications. Cryptography leveraged to protect this information is selected to withstand cryptanalytic attacks for the lifetime of the encrypted key.

CA Private Keys are kept in a physically secure location, and are never stored unencrypted outside of hardware security modules.

6.2.2. Private Key (n out of m) multi-person control

All access to GTS Private Keys requires multiple persons performing in Trusted Roles, for both physical and logical access. This is true for all copies of Private Keys, including backups.

6.2.3. Private Key escrow

The Private Keys of GTS CAs are not escrowed.

6.2.4. Private Key backup

Backups of CA Private Keys are stored in a secure manner in accordance with applicable GTS policy.

6.2.5. Private Key archival

Private Keys belonging to GTS CAs are not archived by parties other than GTS.

6.2.6. Private Key transfer into or from a cryptographic module

Private Keys generated on behalf of a Subordinate CA are encrypted for transport to the Subordinate CA.

All transfers of Private Keys into or from a cryptographic module are performed in accordance with the procedures specified by the vendor of the relevant cryptographic module.

6.2.7. Private Key storage on cryptographic module

See 6.2.1

6.2.8. Method of activating Private Key

Private Keys are activated in accordance with applicable instructions specified by the cryptographic module manufacturer

6.2.9. Method of deactivating Private Key

Private Keys are deactivated in accordance with applicable instructions specified by the cryptographic module manufacturer.

6.2.10. Method of destroying Private Key

Private Keys are destroyed in accordance with applicable instructions specified by the cryptographic module manufacturer. In addition GTS policy on destruction of highly confidential information is followed.

6.2.11. Cryptographic Module Rating

See Section 6.2.1.

6.3. Other aspects of Key Pair management

6.3.1. Public Key archival

No stipulation.

6.3.2. Certificate operational periods and key pair usage periods

Certificates are valid from the moment of signing, unless otherwise specified in the Certificate validity structure, until the Certificate expiration time.

Leaf Certificates are issued for a period of 93 days or less. SXG subscriber certificates are issued for a period of 48 days or less. A day is measured as 86,400 seconds.

6.4. Activation data

6.4.1. Activation data generation and installation

Activation data used to activate GTS CA Private Keys is generated during a key ceremony as described in section 6.1.1. The activation data is transferred to a person performing in a trusted role to use it or store it. The delivery method maintains the confidentiality and the integrity of the activation data.

6.4.2. Activation data protection

GTS CA activation data is protected from unauthorized disclosure via both logical and physical access control mechanisms.

6.4.3. Other aspects of activation data

No stipulation.

6.5. Computer security controls

6.5.1. Specific computer security technical requirements

GTS CA system information is protected from unauthorized access through a combination of operating system controls, physical controls and network security controls. Network security controls are specified in Section 6.7.

CA systems enforce multi-factor authentication for all accounts capable of directly causing Certificate issuance.

6.5.2. Computer security rating

No stipulation.

6.6. Life cycle technical controls

6.6.1. System development controls

GTS uses software that has been formally tested for suitability and fitness for purpose. Hardware is procured through a managed process leveraging industry-standard vendors.

GTS performs linting multiple times throughout the Certificate issuance process.

If there are errors discovered by a lint or check at any point during the issuance process. GTS is alerted and performs an investigation to determine what action needs to be taken.

GTS may perform linting on the corpus of its unexpired, unrevoked Subscriber certificates whenever it updates the linting software.

6.6.2. Security management controls

Google has established an information security organization which implements and operates a framework of internal controls that comprises technical, organizational, and procedural measures. GTS follows applicable Google frameworks and controls.

6.6.3. Life cycle security controls

System access is managed on an individual basis and at several levels including the assignment of operating system privileges to the user accounts of individuals performing in Trusted Roles.

6.7. Network security controls

GTS's certificate systems are protected by Google's security infrastructure and a GTS specific set of controls that implement the CA/Browser Forum's Network and Certificate System Security Requirements.

These controls include:

6.8. Time-stamping

All logs contain synchronized time stamps.

7. CERTIFICATE, CRL, AND OCSP PROFILES

7.1. Certificate profile

Certificates conform to RFC 5280, Internet X.509 Public Key Infrastructure Certificate and CRL Profile. Certificate extensions and their criticality, as well as cryptographic algorithm object identifiers, are populated according to the IETF RFC 5280 standard. Moreover, GTS meets the technical requirements set forth in Section 2.2, Section 6.1.5, and Section 6.1.6.

Where stipulations of RFC 5280 are in conflict with applicable requirements of the CA/Browser Forum, the CA/Browser Forum requirements are followed.

7.1.1. Version number(s)

Certificates are of type X.509 v3.

7.1.2. Certificate content and extensions

This section specifies the additional requirements for certificate content and extensions for certificates.

All certificates GTS issues comply with one of the following certificate profiles derived from RFC 5280. Except as explicitly noted, all normative requirements imposed by RFC 5280 shall apply, in addition to the normative requirements imposed by this document. See RFC 5280, Appendix B for further information.

7.1.2.1. Root CA certificate profile
Field Content
version v3
serialNumber A non-sequential number greater than zero (0) and less than 2¹⁵⁹ containing at least 64 bits of output from a CSPRNG.
signature See section 7.1.3.2
issuer Byte-for-byte identical to the encoded subject
validity See section 7.1.2.1.1
subject Contains countryName, organizationName and commonName.
subjectPublicKeyInfo See section 7.1.3.1
extensions See section 7.1.2.1.2
signatureAlgorithm Byte-for-byte identical to the tbsCertificate.signature.

Note: The GlobalSign R4 root does not follow the current root CA certificate profile as it predates today's standards.

7.1.2.1.1. Root CA validity
Field Minimum Maximum
notBefore One day prior to the time of signing The time of signing
notAfter 2922 days (approx. 8 years) after notBefore 9132 days (approx. 25 years) after notBefore
7.1.2.1.2. Root CA extensions

Any extension not mentioned is always absent from the certificate.

Extension Presence Critical Content
basicConstraints ALWAYS Y cA is TRUE, pathLenConstraint is not set
keyUsage ALWAYS Y keyCertSign and cRLSign are set, digitalSignature may be set, other bits are not set
subjectKeyIdentifier ALWAYS N 160-bit SHA-1 hash of subjectPublicKey [RFC 5280]
7.1.2.1.3. Root CA authority key identifier

No stipulation.

7.1.2.1.4. Root CA basic constraints

See Section 7.1.2.1.2.

7.1.2.2. Cross-certified subordinate CA certificate profile

GTS issues cross-certified subordinate CA Certificates. The Certificate profile is identical to the subordinate TLS CA Certificate profile found in Section 7.1.2.6.

7.1.2.2.1. Cross-certified subordinate CA validity

See Section 7.1.2.6. The notBefore date of cross-certified subordinate CA Certificates is not set before the earliest notBefore date of the existing CA Certificate(s).

7.1.2.2.2. Cross-certified subordinate CA naming

The subject field is byte-for-byte identical to the encoded subject of the existing CA Certificate(s).

7.1.2.2.3. Cross-certified subordinate CA extensions

See Section 7.1.2.6.1.

7.1.2.2.4. Cross-certified subordinate CA extended key usage -- unrestricted

Not applicable. GTS does not have unrestricted cross-certified subordinate CA Certificates.

7.1.2.2.5. Cross-certified subordinate CA extended key usage - restricted

See Section 7.1.2.6.1.

7.1.2.2.6. Cross-certified subordinate CA certificate policies

See Section 7.1.2.6.1.

7.1.2.3. Technically constrained non-TLS subordinate CA certificate profile

Not applicable. GTS does not issue technically constrained non-TLS subordinate CA Certificates.

7.1.2.4. Technically constrained precertificate signing CA certificate profile

Not applicable. GTS does not issue technically constrained precertificate signing CA Certificates.

7.1.2.5. Technically constrained TLS subordinate CA certificate profile

Not applicable. GTS does not issue Technically constrained TLS subordinate CA Certificates.

7.1.2.6. TLS subordinate CA certificate profile

Any field not mentioned is always absent from the Certificate.

Field Content
tbsCertificate 
`version`              | v3
`serialNumber`         | A non-sequential number greater than zero (0) and less than 2¹⁵⁹ containing at least 64 bits of output from a CSPRNG.
`signature`            | See section 7.1.3.2.
`issuer`               | Byte-for-byte identical to the `subject` field of the Issuing CA.
`validity`             |
    `notBefore`        | Not earlier than one day before the time of signing; not later than the time of signing
    `notAfter`         | Not earlier than the time of signing.
`subject`              | Contains `countryName`, `organizationName` and `commonName`
`subjectPublicKeyInfo` | See section 7.1.3.1.
`extensions`           | See section 7.1.2.6.1.

signatureAlgorithm | Byte-for-byte identical to the tbsCertificate.signature. signature |

7.1.2.6.1. TLS subordinate CA extensions

Any extension not mentioned is always absent from the certificate.

Extension Presence Critical Content
authorityKeyIdentifier ALWAYS N Identical to the subjectKeyIdentifier field of the Issuing CA.
basicConstraints ALWAYS Y cA is TRUE, pathLenConstraint field is set to 0.
certificatePolicies ALWAYS N Contains the DV certificate policyIdentifier (2.23.140.1.2.1).
CRLDistributionPoints ALWAYS N HTTP URL of the Issuing CA's CRL service for this certificate.
keyUsage ALWAYS Y keyCertSign and cRLSign are set, digitalSignature may be set, other bits are not set
subjectKeyIdentifier ALWAYS N 160-bit SHA-1 hash of subjectPublicKey [RFC 5280]
extkeyUsage ALWAYS N Includes id-kp-serverAuth and may include id-kp-clientAuth; does not include other values [RFC 5280]
authorityInformationAccess ALWAYS N Contains the HTTP URL of the Issuing CA's certificate and may contain the HTTP URL of the Issuing CA's OCSP responder
7.1.2.7. Subscriber (server) certificate profile
7.1.2.7.1. Subscriber certificate types

GTS issues Domain Validated (DV) TLS Subscriber certificates and Signed HTTP Exchange (SXG) subscriber certificates. Differences between the two profiles are described in the respective subsections below.

7.1.2.7.2. Domain validated

Any field not mentioned is always absent from the certificate or empty.

Field Description
version v3
serialNumber A non-sequential number greater than zero (0) and less than 2¹⁵⁹ containing at least 64 bits of output from a CSPRNG. Unique per Issuing CA.
signature See Section 7.1.3.2.
issuer Byte-for-byte identical to the subject field of the Issuing CA.
validity - notBefore A value within 48 hours of the certificate signing operation.
validity - notAfter See section 6.3.2.
subject Either an empty sequence or contains the commonName only, where the value is derived from the subjectAltName extension according to Section 7.1.4.3.
subjectPublicKeyInfo See Section 7.1.3.1.
extensions See Section 7.1.2.7.6.
signatureAlgorithm Byte-for-byte identical to the tbsCertificate.signature.
7.1.2.7.3. Individual validated

Not applicable. GTS does not issue Individual validated certificates.

7.1.2.7.4. Organization validated

Not applicable. GTS does not issue Organization validated leaf certificates.

7.1.2.7.5. Extended validation

Not applicable. GTS does not issue Extended validation certificates.

7.1.2.7.6. Subscriber certificate extensions

Any extension not mentioned is always absent from the certificate.

7.1.2.7.6.1. TLS extensions
Extension Presence Critical Description {.sortable}
authorityInformationAccess ALWAYS N See section 7.1.2.7.7.
authorityKeyIdentifier ALWAYS N keyIdentifier is identical to the subjectKeyIdentifier field of the Issuing CA.
certificatePolicies ALWAYS N Contains the DV certificate policyIdentifier (2.23.140.1.2.1).
extKeyUsage ALWAYS N Includes id-kp-serverAuth and may include id-kp-clientAuth [RFC 5280]
subjectAltName ALWAYS * Marked critical if subject is empty, not marked critical otherwise. Contains at least one name and all names are of type dNSName or iPAddress.
keyUsage ALWAYS Y digitalSignature bit is always set, keyEncipherment bit is set if the certificate's subjectPublicKeyInfo identifies an RSA public key.
basicConstraints ALWAYS Y cA is FALSE
crlDistributionPoints ALWAYS N Contains the HTTP URL of the Issuing CA's CRL service for this certificate.
Signed Certificate Timestamp List ALWAYS N Contains at least two SignedCertificateTimestamp [RFC 6962] for a PreCert LogEntryType that corresponds to the current certificate.
subjectKeyIdentifier ALWAYS N Contains 160-bit SHA-1 hash of subjectPublicKey [RFC 5280]
7.1.2.7.6.2. SXG extensions
Extension Presence Critical Description {.sortable}
extKeyUsage ALWAYS N Includes id-kp-serverAuth [RFC 5280] only.
canSignHttpExchanges ALWAYS N Contains the NULL value.
Any other extension * * Identical to the table in 7.1.2.7.6.1

Note: canSignHttpExchanges is defined as OID 1.3.6.1.4.1.11129.2.1.22.

7.1.2.7.7. Subscriber certificate authority information access
Access Method OID Access Location Presence Description
id-ad-ocsp 1.3.6.1.5.5.7.48.1 uniformResourceIdentifier OPTIONAL A HTTP URL of the Issuing CA's OCSP responder.
id-ad-caIssuers 1.3.6.1.5.5.7.48.2 uniformResourceIdentifier ALWAYS A HTTP URL of the Issuing CA's certificate.
7.1.2.7.8. Subscriber certificate basic constraints

See section 7.1.2.7.6.

7.1.2.7.9. Subscriber certificate certificate policies

See section 7.1.2.7.6.

7.1.2.7.10. Subscriber certificate extended key usage

See section 7.1.2.7.6.

7.1.2.7.11. Subscriber certificate key usage

See section 7.1.2.7.6.

7.1.2.7.12. Subscriber certificate subject alternative name

See section 7.1.2.7.6.

7.1.2.8. OCSP responder certificate profile

Not applicable. GTS does not issue OCSP responder certificates.

7.1.2.9. Precertificate profile

GTS uses directly issued precertificates only. The precertificate profile is the same as the respective subscriber Certificate profile, except for the differences specified in section 7.1.2.9.1.

7.1.2.9.1. Precertificate profile extensions - directly issued
Extension Presence Critical Description
Precertificate Poison ALWAYS Y Contains an extnValue OCTET STRING of 0500.
Signed Certificate Timestamp List NEVER -
Any other extension * * Identical to the table in section 7.1.2.7.6.
7.1.2.9.2. Precertificate profile extensions - precertificate CA issued

Not applicable. GTS does not issue precertificates with a precertificate CA.

7.1.2.9.3. Precertificate poison

See section 7.1.2.9.1.

7.1.2.9.4. Precertificate authority key identifier

Not applicable. GTS does not issue precertificates with a precertificate CA.

7.1.2.10. Common CA fields

No stipulation.

7.1.3. Algorithm object identifiers

GTS does not issue any subscriber Certificates or subordinate CA Certificates using the SHA-1 hash algorithm.

7.1.3.1. SubjectPublicKeyInfo

The following requirements apply to the subjectPublicKeyInfo field within a certificate or precertificate. No other encodings are permitted.

7.1.3.1.1. RSA

GTS follows the BRs for indicating usage of RSA.

7.1.3.1.2. ECDSA

GTS follows the BRs for P-256 and P-384 keys.

GTS does not support P-521 keys.

7.1.3.2. Signature AlgorithmIdentifier

GTS conforms to all the requirements for the usage of the AlgorithmIdentifier and AlgorithmIdentifier-derived type in the context of signatures listed in the BRs.

7.1.3.2.1. RSA

GTS uses the following signature algorithms and its corresponding encodings from the BRs:

7.1.3.2.2. ECDSA

GTS uses the appropriate signature algorithm and encoding based upon the signing key as stated in the BRs for P-256 and P-384 signing keys.

GTS does not sign with P-521 keys.

7.1.4. Name forms

This section details encoding rules that apply to all Certificates issued by GTS. Further restrictions may be specified within Section 7.1.2. These restrictions do not supersede these requirements.

7.1.5. Name constraints

No stipulation.

7.1.6. Certificate policy object identifier

7.1.6.1. Reserved certificate policy identifiers

Root CA certificates do not contain the certificatePolicies extension.

Subscriber certificates include one or more of the following Object Identifiers, depending on their type and the method of validation used.

7.1.7. Usage of policy constraints extension

No stipulation.

7.1.8. Policy qualifiers syntax and semantics

No stipulation.

7.1.9. Processing semantics for the critical Certificate Policies extension

No stipulation.

7.2. CRL profile

GTS issues CRLs in accordance with the profile specified below.

GTS does not issue indirect CRLs.

Field Content
version v2
signature See section 7.1.3.
issuer Byte-for-byte identical to the subject field of the Issuing CA
thisUpdate Issue date of the CRL
nextUpdate For CRLs covering Subscriber Certificates, at most 10 days after the thisUpdate. For other CRLs, at most 12 months after the thisUpdate
revokedCertificates Certificates that have been revoked and the corresponding entry has yet to appear on at least one regularly scheduled CRL beyond the revoked Certificate's validity period.
extensions See the "CRL Extensions" table in section 7.2.2.
signatureAlgorithm Encoded value Byte-for-byte identical to the tbsCertList signature.
signature Signature covering the CRL signed by the associated CA.

7.2.1. Version number(s)

Certificate Revocation Lists are of type X.509 v2.

7.2.2. CRL and CRL entry extensions

Table: CRL Extensions

Any other extension or field is always absent from the CRL.

Extension Presence Critical Content
authorityKeyIdentifier ALWAYS N Identical to the subjectKeyIdentifier field of the Issuing CA.
CRLNumber ALWAYS N INTEGER greater than or equal to zero (0) and less than 2¹⁵⁹, and follows a strictly increasing sequence
IssuingDistributionPoint * Y See section 7.2.2.1.

Table: revokedCertificates Component

Component Presence Content
serialNumber ALWAYS Byte-for-byte identical to the serialNumber contained in the revoked certificate.
revocationDate ALWAYS Date and time of revocation. The revocation date may be backdated if the reasonCode is keyCompromise.
crlEntryExtensions * See the "crlEntryExtensions Component" table

Table: crlEntryExtensions Component

Any other extension or field is always absent from the CRL.

CRL Entry Extension Content
reasonCode When present (OID 2.5.29.21), not marked critical and indicates the most appropriate reason for revocation of the Certificate.

Present unless the CRL entry is for a certificate not technically capable of causing issuance and the revocation reason is unspecified (0).

GTS supports all RFC 5280 reasonCodes listed in the BRs except for the affiliationChanged reasonCode.

Tools that GTS provides to the Subscriber allow for these options to be easily specified when the Subscriber requests revocation of their certificate, with the default value being that no revocation reason is provided (i.e. the default corresponds to the CRLReason "unspecified (0)" which results in no reasonCode extension being provided in the CRL). For revocation requests made via ACME, the reason code can be selected during the ACME workflow.

The privilegeWithdrawn reasonCode is not available to the Subscriber as a revocation reason option, because the use of this reasonCode is determined by GTS and not the Subscriber.

When GTS obtains verifiable evidence of Key Compromise for a certificate whose CRL entry does not contain a reasonCode extension or has a reasonCode extension with a non-keyCompromise reason, GTS may update the CRL entry to enter keyCompromise as the CRLReason in the reasonCode extension. Additionally, GTS may update the revocation date in a CRL entry when it is determined that the private key of the certificate was compromised prior to the revocation date that is indicated in the CRL entry for that certificate.

7.2.2.1 CRL issuing distribution point

GTS only uses partitioned CRLs for subscriber Certificates and follows the requirements listed in the BRs.

The indirectCRL and onlyContainsAttributeCerts fields are set to FALSE.

7.3. OCSP profile

GTS provides an OCSP service for TLS certificates which conforms to the RFC 6960 standard.

If an OCSP response is for a Root CA or Subordinate CA Certificate, including Cross-Certified Subordinate CA Certificates, and that certificate has been revoked, then the revocationReason field within the RevokedInfo of the CertStatus is present.

The CRLReason indicated contains a value permitted for CRLs, as specified in Section 7.2.2.

7.3.1. Version number(s)

No stipulation.

7.3.2. OCSP extensions

The singleExtensions of OCSP responses does not contain the reasonCode (OID 2.5.29.21) CRL entry extension.

8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS

8.1. Frequency or circumstances of assessment

Compliance audits are conducted at least annually.

8.2. Identity/qualifications of assessor

Compliance audits of GTS CAs are performed by a public accounting firm that possesses the following qualifications and skills:

  1. Independence from the subject of the audit;
  2. The ability to conduct an audit against the WebTrust Principles and Criteria for Certification Authorities;
  3. Employs individuals who have proficiency in examining Public Key Infrastructure technology, information security tools and techniques, information technology and security auditing, and the third-party attestation function;
  4. Is a licensed WebTrust practitioner;
  5. Is bound by law, government regulation, or a professional code of ethics; and
  6. Except in the case of an Internal Government Auditing Agency, maintains Professional Liability/Errors & Omissions insurance with policy limits of at least one million US dollars in coverage.

8.3. Assessor's relationship to assessed entity

Compliance audits of GTS CAs are performed by a public accounting firm that is independent of the subject of the audit.

8.4. Topics covered by assessment

Annual compliance audits of GTS CAs include an assessment of the controls GTS has implemented to ensure the secure operation of its CAs. In particular they cover an assessment of GTS's compliance with the applicable WebTrust Principles and Criteria for Certification Authorities as published by CPA Canada.

The Audit Reports are published at (https://pki.goog/).

8.5. Actions taken as a result of deficiency

If a material deficiency in the design or operation of a control is identified during an audit, GTS's CA Policy Authority determines whether remediating actions are required and how these will be implemented. GTS seeks the input of its Qualified Auditor regarding the remediation plans it makes and implements the remediation action within a commercially reasonable period of time.

8.6. Communication of results

The Audit Report is made publicly available no later than three months after the end of the audit period. GTS is not required to make publicly available any general audit findings that do not impact the overall audit opinion. In the event of a delay greater than three months, and if so requested by an Application Software Supplier, GTS will provide an explanatory letter signed by its Qualified Auditor.

The Audit Report covers the relevant systems and processes used in the issuance of all Certificates that assert one or more of the policy identifiers listed in Section 7.1.6.1. The Audit Report states explicitly which CAs, certification practices, and locations it covers.

8.7. Self-Audits

GTS performs quarterly internal audits of the Certificates it issues, which audits comply with the requirements of Section 8.7 of the CABF TLS Baseline Requirements.

GTS does not use Delegated Third Parties in the Certificate Management Process. All third parties who are involved in performing or fulfilling the requirements of this CP/CPS are within the scope of GTS's audits.

9.1. Fees

9.1.1. Certificate issuance or renewal fees

GTS may charge Subscribers for the issuance, management and renewal of Certificates. GTS does not charge for the revocation of certificates it has issued.

9.1.2. Certificate access fees

No stipulation.

9.1.3. Revocation or status information access fees

GTS does not charge a fee as a condition of making the CRLs required by this CP/CPS available in a Repository or otherwise available to Relying Parties. GTS may however charge a fee for providing customized CRLs, OCSP services, or other value-added revocation and status information services. GTS does not permit access to revocation information, Certificate status information, or time stamping in its Repository by third parties that provide products or services that utilize such Certificate status information without GTS's prior express written consent.

9.1.4. Fees for other services

GTS does not charge a fee for access to this CP/CPS. Any use made for purposes other than simply viewing the document, such as reproduction, redistribution, modification, or creation of derivative works, shall be subject to a license agreement with GTS.

9.1.5. Refund policy

No stipulation.

9.2. Financial responsibility

9.2.1. Insurance coverage

Google maintains general liability insurance coverage inclusive of GTS.

9.2.2. Other assets

No stipulation.

9.2.3. Insurance or warranty coverage for end-entities

No stipulation.

9.3. Confidentiality of business information

9.3.1. Scope of confidential information

No stipulation.

9.3.2. Information not within the scope of confidential information

Certificates and revocation data are not considered confidential information. Furthermore information is not considered confidential if its disclosure is mandated pursuant to this CP/CPS.

9.3.3. Responsibility to protect confidential information

No stipulation.

9.4. Privacy of personal information

9.4.1. Privacy plan

GTS follows the Google Privacy Policy available at: https://www.google.com/policies/privacy/

9.4.2. Information treated as private

See Section 9.4.1.

9.4.3. Information not deemed private

See Section 9.4.1.

9.4.4. Responsibility to protect private information

See Section 9.4.1.

See Section 9.4.1.

9.4.6. Disclosure pursuant to judicial or administrative process

See Section 9.4.1.

9.4.7. Other information disclosure circumstances

See Section 9.4.1.

9.5. Intellectual property rights

GTS and its licensors, own the intellectual property rights in the GTS CA services, including the Certificates, trademarks used in providing Certificate services and this CP/CPS.

Certificate and revocation information are the exclusive property of GTS. GTS grants permission to reproduce and distribute certificates on a non-exclusive and royalty-free basis, provided that they are reproduced and distributed in full. GTS does not allow derivative works of its Certificates or products without prior written permission.

Private and Public Keys remain the property of the Subscribers who rightfully hold them. All secret shares (distributed elements) of the GTS Private Keys are the property of GTS.

9.6. Representations and warranties

9.6.1. CA representations and warranties

By issuing a Certificate, GTS makes the certificate warranties listed in 9.6.1 of the CABF TLS Baseline Requirements.

9.6.2. RA representations and warranties

No stipulation.

9.6.3. Subscriber representations and warranties

GTS requires, as part of the Subscriber Agreement, that the Applicant make the commitments and warranties in BR Section 9.6.3 for the benefit of GTS and the Certificate Beneficiaries.

The Subscriber Agreement may include additional representations and warranties.

9.6.4. Relying party representations and warranties

Relying Parties represent and warrant that: (a) they have read, understand and agree to this CP/CPS; (b) they have verified both the relevant GTS CA's certificate and any other certificates in the certificate chain using the relevant CRL or OCSP; (c) they will not use a certificate if the certificate has expired or been revoked; (d) they have sufficient information to make an informed decision as to the extent to which they choose to rely on the information in a certificate; (e) they have studied the applicable limitations on the usage of certificates and agree to GTS's limitations on liability related to the use of certificates; (f) they are solely responsible for deciding whether or not to rely on information in a certificate; and (g) they are solely responsible for the legal and other consequences of their failure to perform the Relying Party obligations in this CP/CPS.

Relying Parties also represent and warrant that they will take all reasonable steps to minimize the risk associated with relying on a digital signature, including only relying on a certificate after considering:

  1. Applicable law and the legal requirements for identification of a party, protection of the confidentiality or privacy of information, and enforceability of the transaction;

  2. The intended use of the certificate as listed in the Certificate or this CP/CPS;

  3. The data listed in the Certificate;

  4. The economic value of the transaction or communication;

  5. The potential loss or damage that would be caused by an erroneous identification or a loss of confidentiality or privacy of information in the application, transaction, or communication;

  6. The Relying Party's previous course of dealing with the Subscriber;

  7. The Relying Party's understanding of trade, including experience with computer-based methods of trade; and

  8. Any other indicia of reliability or unreliability pertaining to the Subscriber and/or the application, communication, or transaction.

The Relying Party Agreement may include additional representations and warranties.

9.6.5. Representations and warranties of other participants

No stipulation.

9.7. Disclaimers of warranties

EXCEPT AS EXPRESSLY STATED IN SECTION 9.6.1 OF THIS CP/CPS, ALL CERTIFICATES AND ANY RELATED SOFTWARE AND SERVICES ARE PROVIDED "AS IS" AND "AS AVAILABLE." TO THE MAXIMUM EXTENT PERMITTED BY LAW, GTS DISCLAIMS ALL OTHER WARRANTIES, BOTH EXPRESS AND IMPLIED, INCLUDING, WITHOUT LIMITATION, ANY IMPLIED WARRANTY OF MERCHANTABILITY, ANY WARRANTY OF FITNESS FOR A PARTICULAR PURPOSE AND ANY WARRANTY OF ACCURACY OF INFORMATION PROVIDED WITH RESPECT TO CERTIFICATES ISSUED BY GTS, THE CRL, AND ANY PARTICIPANT'S OR THIRD PARTY'S PARTICIPATION IN THE GTS PKI, INCLUDING USE OF KEY PAIRS, CERTIFICATES, THE CRL OR ANY OTHER GOODS OR SERVICES PROVIDED BY GTS TO THE PARTICIPANT.

EXCEPT AS EXPRESSLY STATED IN SECTION 9.6.1 OF THIS CP/CPS, GTS DOES NOT WARRANT THAT ANY SERVICE OR PRODUCT WILL MEET ANY EXPECTATIONS OR THAT ACCESS TO CERTIFICATES WILL BE TIMELY OR ERROR-FREE.

GTS does not guarantee the availability of any products or services and may modify or discontinue any product or service offering at any time. A fiduciary duty is not created simply because an individual or entity uses GTS's services.

9.8. Limitations of liability

TO THE EXTENT PERMITTED BY APPLICABLE LAW, GTS SHALL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL, CONSEQUENTIAL, EXEMPLARY OR PUNITIVE DAMAGES, INCLUDING BUT NOT LIMITED TO DAMAGES FOR LOST DATA, LOST PROFITS, LOST REVENUE OR COSTS OF PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES, HOWEVER CAUSED AND UNDER ANY THEORY OF LIABILITY, INCLUDING BUT NOT LIMITED TO CONTRACT OR TORT (INCLUDING PRODUCTS LIABILITY, STRICT LIABILITY AND NEGLIGENCE), AND WHETHER OR NOT IT WAS, OR SHOULD HAVE BEEN, AWARE OR ADVISED OF THE POSSIBILITY OF SUCH DAMAGE AND NOTWITHSTANDING THE FAILURE OF ESSENTIAL PURPOSE OF ANY LIMITED REMEDY STATED HEREIN. GTS'S AGGREGATE LIABILITY UNDER THIS CP/CPS IS LIMITED TO $500.

9.9. Indemnities

GTS shall defend, indemnify, and hold harmless each Application Software Supplier for any and all claims, damages, and losses suffered by such Application Software Supplier related to a Certificate issued by GTS, regardless of the cause of action or legal theory involved. This does not apply, however, to any claim, damages, or loss suffered by such Application Software Supplier related to a Certificate issued by GTS where such claim, damage, or loss was directly caused by such Application Software Supplier’s software displaying as not trustworthy a Certificate that is still valid, or displaying as trustworthy: (1) a Certificate that has expired, or (2) a Certificate that has been revoked (but only in cases where the revocation status is currently available from GTS, and the application software either failed to check such status or ignored an indication of revoked status).

9.10. Term and termination

9.10.1. Term

New versions of this CP/CPS supersede all previous versions and become effective upon publication in the Repository.

9.10.2. Termination

This CP/CPS and any amendments remain in effect until replaced by a newer version.

9.10.3. Effect of termination and survival

Upon termination of this CP/CPS, Participants are nevertheless bound by its terms for all Certificates issued for the remainder of the validity periods of such Certificates.

9.11. Individual notices and communications with participants

Unless otherwise specified by agreement between the parties, Participants shall use commercially reasonable methods to communicate with each other, taking into account the criticality and subject matter of the communication.

9.12. Amendments

9.12.1. Procedure for amendment

GTS may change this CP/CPS at any time in its sole discretion and without prior notice to Subscribers or Relying Parties. The CP/CPS and any amendments thereto are available in the Repository. Amendments to this CP/CPS will be evidenced by a new version number and date, except where the amendments are purely clerical.

9.12.2. Notification mechanism and period

GTS may provide additional notice (such as in the Repository or on a separate website) in the event that it makes any material changes to its CP/CPS. GTS is responsible for determining what constitutes a material change of the CP/CPS. GTS does not guarantee or set a notice-and-comment period.

9.12.3. Circumstances under which OID must be changed

No stipulation.

9.13. Dispute resolution provisions

No stipulation.

9.14. Governing law

This CP/CPS is governed by the laws of the State of California of the United States of America, excluding (i) its choice of laws principles, and (ii) the United Nations Convention on Contracts for the International Sale of Goods. All Participants hereby submit to the exclusive jurisdiction and venue of the federal or state courts in Santa Clara County, California.

9.15. Compliance with applicable law

GTS shall issue Certificates and operate its PKI in accordance with all law applicable to its business and the Certificates it issues in every jurisdiction in which it operates. This CP/CPS is subject to applicable national, state, local and foreign laws, rules, regulations, ordinances, decrees, and orders including, but not limited to, restrictions on exporting or importing software, hardware, or technical information. GTS licenses its CAs in each jurisdiction that it operates where licensing is required by the law of such jurisdiction for the issuance of Certificates.

9.16. Miscellaneous provisions

9.16.1. Entire agreement

No stipulation.

9.16.2. Assignment

GTS is free to assign its rights and obligations under this CP/CPS. Relying Parties and Subscribers may not assign their rights (if any) or obligations under this CP/CPS, by operation of law or otherwise, without GTS's prior written approval. Any such attempted assignment shall be void. Subject to the foregoing, this CP/CPS shall be binding upon and inure to the benefit of the parties hereto, their successors and permitted assigns.

9.16.3. Severability

No stipulation.

9.16.4. Enforcement (attorneys' fees and waiver of rights)

GTS may seek indemnification and attorneys' fees from a party for damages, losses, and expenses related to that party's conduct. GTS's failure to enforce a provision of this CP/CPS does not waive GTS's right to enforce the same provision later or right to enforce any other provision of this CPS. To be effective, waivers must be in writing and signed by GTS.

9.16.5. Force majeure

GTS shall not be liable for any default or delay in the performance of its obligations hereunder to the extent and while such default or delay is caused, directly or indirectly, by fire, flood, earthquake, elements of nature or acts of God, acts of war, terrorism, riots, civil disorders, rebellions or revolutions in the United States, strikes, lockouts, or labor difficulties or any other similar cause beyond the reasonable control of GTS.

9.17. Other provisions

No stipulation.

Appendix A: Definitions, Acronyms and References

Definitions

Automatic Certificate Management Environment (ACME): A communications protocol for automating interactions between Certificate Authorities and their Subscribers.

Affiliate: A corporation, partnership, joint venture or other entity controlling, controlled by, or under common control with another entity, or an agency, department, political subdivision, or any entity operating under the direct control of a Government Entity.

Applicant: The natural person or Legal Entity that applies for (or seeks renewal of) a certificate. Once the certificate is issued, the Applicant is referred to as the Subscriber. For certificates issued to devices, the Applicant is the entity that controls or operates the device named in the certificate, even if the device is sending the actual certificate request.

Application Software Supplier: A supplier of Internet browser software or other relying-party application software (web-based or application based) that processes, displays or uses Certificates and incorporates Root Certificates.

Audit Period: In a period-of-time audit, the period between the first day (start) and the last day of operations (end) covered by the audit opinion.

Audit Report: A report from a Qualified Auditor stating the Qualified Auditor's opinion on GTS's internal controls over its CA operations in relation to applicable audit criteria.

Authorization Domain Name: The FQDN used to obtain authorization for a given FQDN to be included in a certificate. GTS may use the FQDN returned from a DNS CNAME lookup as the FQDN for the purposes of domain validation. If a Wildcard Domain Name is to be included in a certificate, then GTS removes "'*.'" from the left-most portion of the Wildcard Domain Name to yield the corresponding FQDN. GTS may prune zero or more Domain Labels of the FQDN from left to right until encountering a Base Domain Name and may use any one of the values that were yielded by pruning (including the Base Domain Name itself) for the purpose of domain validation.

Authorized Ports: One of the following ports: 80 (http), 443 (https), 25 (smtp), 22 (ssh).

CABF TLS Baseline Requirements or BR: CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates, available at https://cabforum.org/baseline-requirements-documents/

CAA: From RFC 8659 (http://tools.ietf.org/html/rfc8659): "The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify one or more Certification Authorities (CAs) authorized to issue certificates for that domain name. CAA Resource Records allow a public CA to implement additional controls to reduce the risk of unintended certificate mis-issue."

CA Key Pair: A Key Pair where the Public Key appears as the Subject Public Key Info in one or more Root CA certificate(s) and/or Subordinate CA certificate(s).

CA Services: Services relating to the creation, issuance, or management of Certificates provided by GTS under this CP/CPS.

Certificate: An electronic document that uses a digital signature to bind a Public Key and an identity. In the context of this document it always refers to TLS Server Certificates.

Certificate Policy (CP): This document.

Certificate Problem Report: Complaint of suspected Key Compromise, certificate misuse, or other types of fraud, compromise, misuse, or inappropriate conduct related to certificates.

Certificate Profile: A set of documents or files that defines requirements for certificate content and certificate extensions in accordance with Section 7.

Certificate Revocation List (CRL): A regularly updated time-stamped list of revoked certificates that is created and digitally signed by the CA that issued the certificates.

Certification Authority (CA): An organization that is responsible for the creation, issuance, revocation, and management of certificates. The term applies equally to both Roots CAs and Subordinate CAs. The term CA can depending on the context also refer to the infrastructure used by that organization to provide CA Services.

Cross Certificate: A certificate that is used to establish a trust relationship between two Root CAs.

Cross-Certified Subordinate CA Certificate: A certificate that is used to establish a trust relationship between two CAs.

CSPRNG: A pseudo-random number generator intended for use in a cryptographic system.

Delegated Third Party: A Natural Person or Legal Entity that is not the CA but is authorized by GTS, and whose activities are not within the scope of the appropriate CA audits, to assist in the certificate management process by performing or fulfilling one or more of the CA requirements found herein.

Domain Contact: The Domain Name Registrant, technical contact, or administrative contact (or the equivalent under a ccTLD) for a Base Domain Name.

Domain Name: An ordered list of one or more Domain Labels assigned to a node in the Domain Name System.

Domain Validated (DV) Certificate: A certificate which verifies that the Subscriber controls the domain names and IP addresses included in the certificate.

Expiry Date: The "Not After" date in a certificate that defines the end of a certificate's validity period.

Fully-Qualified Domain Name (FQDN): A Domain Name that includes the Domain Labels of all superior nodes in the Internet Domain Name System.

FIPS: (US Government) Federal Information Processing Standard

GTS: Google Trust Services Europe Ltd for Subscribers in the EU and Google Trust Services LLC (a Delaware corporation) for all other Subscribers.

GTS Affiliate: An entity that is controlled with or by or is under common control with GTS.

GTS CA: A CA operated by GTS in accordance with this CP/CPS and listed in Section 1.3.1 of this CP/CPS.

GTS Certificate: A certificate issued by a GTS CA under this CP/CPS.

GTS PKI: The GTS Public Key Infrastructure established, operated and maintained by GTS for publicly trusted certificates.

Identification and Authentication (I&A): The process for ascertaining and confirming through appropriate inquiry and investigation the identity and authority of a person or entity. See Section 3.2.

Individual-Validated (IV): Refers to a Certificate Subject that includes only Individual (Natural Person) attributes, rather than attributes linked to an Organization.

Information Security Team: Google employees who belong to a Privacy & Security organization.

Internal Name: 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.

IP Address: A 32-bit or 128-bit number assigned to a device that uses the Internet Protocol for communication.

IP Address Contact: The person(s) or entity(ies) registered with an IP Address Registration Authority as having the right to control how one or more IP Addresses are used.

IP Address Registration Authority: The Internet Assigned Numbers Authority (IANA) or a Regional Internet Registry (RIPE, APNIC, ARIN, AfriNIC, LACNIC).

Issuing CA: In relation to a particular certificate, the CA that issued the certificate. This could be either a Root CA or a Subordinate CA.

Key Compromise: A Private Key is said to be compromised if its value has been disclosed to an unauthorized person, or an unauthorized person has had access to it.

Key Generation Script: A documented plan of procedures for the generation of a CA Key Pair.

Key Pair: Two mathematically related numbers, referred to as a Public Key and its corresponding Private Key, possessing properties such that: (i) the Public Key may be used to verify a Digital Signature generated by the corresponding Private Key; and/or (ii) the Public Key may be used to encrypt an electronic record that can be decrypted only by using the corresponding Private Key.

Linting: A process in which the content of digitally signed data such as a Precertificate [RFC 6962], Certificate, Certificate Revocation List, or OCSP response, or data-to-be-signed object such as a 'tbsCertificate' (as described in RFC 5280, Section 4.1.1.1) is checked for conformance with the profiles and requirements defined in these requirements.

Multi-Perspective Issuance Corroboration: A process by which the determinations made during domain validation and CAA checking by the Primary Network Perspective are corroborated by other Network Perspectives before certificate issuance.

Natural Person: An Individual; a human being as distinguished from a Legal Entity.

Network Perspective: Related to Multi-Perspective Issuance Corroboration. A system (e.g., a cloud-hosted server instance) or collection of network components (e.g., a VPN and corresponding infrastructure) for sending outbound Internet traffic associated with a domain control validation method and/or CAA check. The location of a Network Perspective is determined by the point where unencapsulated outbound Internet traffic is typically first handed off to the network infrastructure providing Internet connectivity to that perspective.

NIST: (US Government) National Institute of Standards and Technology

OCSP: Online Certificate Status Protocol

OID / Object Identifier: A unique alphanumeric or numeric identifier registered under the International Organization for Standardization's applicable standard for a specific object or object class.

OCSP Responder: An online server operated under the authority of GTS and connected to its Repository for processing certificate status requests. See also, Online Certificate Status Protocol.

Online Certificate Status Protocol: An online certificate-checking protocol that enables relying-party application software to determine the status of an identified certificate. See also OCSP Responder.

Organization Validated (OV) Certificate: A certificate which includes the Subscriber's organization name.

Parent Company: A company that controls a subsidiary company.

Participants: The persons authorized to participate in the GTS PKI, as identified in Section 1.3. This term includes the GTS CAs, and each Subscriber and Relying Party operating under the authority of the GTS PKI.

Primary Network Perspective: The Network Perspective used by GTS to make the determination of 1. GTS's authority to issue a Certificate for the requested domain(s) or IP address(es) and 2. the Applicant's authority and/or domain authorization or control of the requested domain(s) or IP address(es).

Private Key: The key of a Key Pair that is kept secret by the holder of the Key Pair, and that is used to create Digital Signatures and/or to decrypt electronic records or files that were encrypted with the corresponding Public Key.

Public Key: The key of a Key Pair that may be publicly disclosed by the holder of the corresponding Private Key and that is used by a Relying Party to verify Digital Signatures created with the holder's corresponding Private Key and/or to encrypt messages so that they can be decrypted only with the holder's corresponding Private Key.

Publicly-Trusted Certificate: A certificate that is trusted by virtue of the fact that its corresponding Root Certificate is distributed as a trust anchor in widely-available application software.

Qualified Auditor: A Natural Person or Legal Entity that meets the requirements of Section 8.2.

Random Value: A value specified by a CA to the Applicant that exhibits at least 112 bits of entropy.

Registration Authority or RA: Any Legal Entity that is responsible for identification and authentication of subjects of certificates, but is not a CA, and hence does not sign or issue certificates. An RA MAY assist in the certificate application process or revocation process or both. When "RA" is used as an adjective to describe a role or function, it does not necessarily imply a separate body, but can be part of the CA.

Reliable Data Source: An identification document or source of data used to verify Subject Identity Information that is generally recognized among commercial enterprises and governments as reliable, and which was created by a third party for a purpose other than the Applicant obtaining a certificate.

Relying Party: Any Natural Person or Legal Entity that relies on a valid certificate. An Application Software Supplier is not considered a Relying Party when software distributed by such Supplier merely displays information relating to a certificate.

Repository: An online accessible database in the GTS PKI containing this CP/CPS, the CRL for revoked GTS certificates, and any other information specified by GTS.

Request Token: A value derived in a method specified by GTS and used to demonstrate domain control.

The Request Token incorporates the key used in the certificate request.

A Request Token includes a timestamp to indicate when it was created and other information to ensure its uniqueness.

A Request Token that includes a timestamp remains valid for no more than 30 days from the time of creation and is treated as invalid if its timestamp is in the future. A Request Token that does not include a timestamp is valid for a single use and GTS does not re-use it for a subsequent validation.

Reserved IP Address: An IPv4 or IPv6 address that is contained in the address block of any entry in either of the following IANA registries: reserved: https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml

Revocation: The process of requesting and implementing a change in the status of a certificate from valid to revoked.

Root CA: The top level Certification Authority whose Root Certificate is distributed by Application Software Suppliers and that issues Subordinate CA Certificates.

Root Certificate: The self-signed certificate issued by the Root CA to identify itself and to facilitate verification of certificates issued to its Subordinate CAs.

Short-lived Subscriber Certificate: For certificates issued on or after 15 March 2024 and prior to 15 March 2026, a Subscriber Certificate with a Validity Period less than or equal to 10 days (864,000 seconds). For certificates issued on or after 15 March 2026, a Subscriber Certificate with a Validity Period less than or equal to 7 days (604,800 seconds).

Subject: The Natural Person, device, system, unit, or Legal Entity identified in a certificate as the Subject. The Subject is either the Subscriber or a device under the control and operation of the Subscriber.

Subordinate CA: A Certification Authority whose certificate is signed by the Root CA, or another Subordinate CA.

Subscriber: A Natural Person or Legal Entity to whom a Certificate is issued and who is legally bound by a Subscriber Agreement or Terms of Use.

Subscriber Agreement: The contract between GTS and a Subscriber whereby the Subscriber agrees to the terms required by this CP/CPS with respect to each certificate issued to the Subscriber and naming the Subscriber as the Subject.

Subsidiary Company: A company that is controlled by or under common control of a Parent Company.

Technically Constrained Subordinate CA Certificate: A Subordinate CA Certificate which uses a combination of Extended Key Usage and/or Name Constraint extensions, as defined within the relevant Certificate Profiles of this document, to limit the scope within which the Subordinate CA Certificate may issue Subscriber or additional Subordinate CA Certificates.

Terms of Use: Provisions regarding the safekeeping and acceptable uses of a Certificate issued in accordance with the BR when the Applicant or Subscriber is a GTS or a Google Affiliate.

Test Certificate: A certificate which is issued under a CA where there are no certificate paths/chains to a root certificate subject to these requirements.

TLS: Transport Layer Security

Validity Period: From RFC 5280: "The period of time from notBefore through notAfter, inclusive."

Wildcard Certificate: A certificate containing at least one Wildcard Domain Name in the Subject Alternative Names in the certificate.

Wildcard Domain Name: A string starting with "*." (U+002A ASTERISK, U+002E FULL STOP) immediately followed by a Fully-Qualified Domain Name.

XN-Label: From RFC 5890: "The class of labels that begin with the prefix "xn--" (case independent), but otherwise conform to the rules for LDH labels."

Acronyms

AICPA, American Institute of Certified Public Accountants

BR, CA/Browser Forum TLS Baseline Requirements

CA, Certificate Authority

CAA, Certificate Authority Authorization

ccTLD, Country Code Top-Level Domain

CP, Certificate Policy

CPS, Certification Practice Statement

CRL, Certificate Revocation List

DBA, Doing Business As

DNS, Domain Name System

ETSI, European Telecommunications Standards Institute

FIPS, (US Government) Federal Information Processing Standard

FQDN, Fully-Qualified Domain Name

IANA, Internet Assigned Numbers Authority

ICANN, Internet Corporation for Assigned Names and Numbers

ICAO, International Civil Aviation Organization

ISO, International Organization for Standardization

MPIC, Multi-perspective issuance corroboration

NIST, (US Government) National Institute of Standards and Technology

OCSP, Online Certificate Status Protocol

OID, Object Identifier

PKI, Public Key Infrastructure

RA, Registration Authority

TLD, Top-Level Domain

TLS, Transport Layer Security

References

ETSI EN 319 403, Electronic Signatures and Infrastructures (ESI); Trust Service Provider Conformity Assessment - Requirements for conformity assessment bodies assessing Trust Service Providers.

ETSI EN 319 403-1, Electronic Signatures and Infrastructures (ESI); Trust Service Provider Conformity Assessment; Part 1 - Requirements for conformity assessment bodies assessing Trust Service Providers.

ETSI EN 319 411-1, Electronic Signatures and Infrastructures (ESI); Policy and security requirements for Trust Service Providers issuing Certificates; Part 1: General requirements.

ETSI EN 319 411-2, Electronic Signatures and Infrastructures (ESI); Policy and security requirements for Trust Service Providers issuing Certificates; Part 2: Requirements for trust service providers issuing EU qualified Certificates.

ETSI EN 319 412-1, Electronic Signatures and Infrastructures (ESI); Certificate Profiles; Part 1: Overview and common data structures.

ETSI EN 319 412-5, Electronic Signatures and Infrastructures (ESI); Certificate Profiles; Part 5: QCStatements.

ETSI TS 102 042, Electronic Signatures and Infrastructures (ESI); Policy requirements for certification authorities issuing public key certificates.

ETSI TS 119 495, Electronic Signatures and Infrastructures (ESI); Sector Specific Requirements; Certificate Profiles and TSP Policy Requirements for Open Banking.

ETSI TS 119 172-4, Electronic Signatures and Infrastructures (ESI); Signature Policies;. Part 4: Signature applicability rules.

FIPS 140-2, Federal Information Processing Standards Publication - Security Requirements For Cryptographic Modules, Information Technology Laboratory, National Institute of Standards and Technology, May 25, 2001.

FIPS 140-3, Federal Information Processing Standards Publication - Security Requirements For Cryptographic Modules, Information Technology Laboratory, National Institute of Standards and Technology, March 22, 2019.

FIPS 186-4, Federal Information Processing Standards Publication - Digital Signature Standard (DSS), Information Technology Laboratory, National Institute of Standards and Technology, July 2013.

ICAO DOC 9303, Machine Readable Travel Documents, Part 10, Logical Data Structure (LDS) for Storage of Biometrics and Other Data in the Contactless Integrated Circuit (IC), International Civil Aviation Organization, Eighth Edition, 2021.

ICAO DOC 9303, Machine Readable Travel Documents, Part 11, Security Mechanisms for MRTDs, International Civil Aviation Organization, Eighth Edition, 2021.

Internet Draft: ACME IP Identifier Validation Extension, R. Shoemaker, July 2018, https://tools.ietf.org/html/draft-ietf-acme-ip-04.

ISO 17065:2012, Conformity assessment - Requirements for bodies certifying products, processes and services.

ISO 17442-1:2020, Financial services - Legal entity identifier (LEI) - Part 1: Assignment.

ISO 17442-2:2020, Financial services - Legal entity identifier (LEI) - Part 2: Application in digital Certificates.

ISO 21188:2006, Public key infrastructure for financial services -- Practices and policy framework.

Network and Certificate System Security Requirements, Version 1.7, available at https://cabforum.org/network-security-requirements/.

NIST SP 800-89, Recommendation for Obtaining Assurances for Digital Signature Applications. https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-89.pdf.

RFC 2119, Request for Comments: 2119, Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. March 1997.

RFC 3492, Request for Comments: 3492, Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA). A. Costello. March 2003.

RFC 3647, Request for Comments: 3647, Internet X.509 Public Key Infrastructure: Certificate Policy and Certification Practices Framework. S. Chokhani, et al, November 2003.

RFC 3739, Request for Comments: 3739, Internet X.509 Public Key Infrastructure: Qualified Certificates Profile, S. Santesson, et al. March 2004.

RFC 3986, Request for Comments: 3986, Uniform Resource Identifier (URI): Generic Syntax. T. Berners-Lee, et al. January 2005.

RFC 5019, Request for Comments: 5019, The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments. A. Deacon, et al. September 2007.

RFC 5280, Request for Comments: 5280, Internet X.509 Public Key Infrastructure: Certificate and Certificate Revocation List (CRL) Profile. D. Cooper, et al. May 2008.

RFC 5322, Request for Comments: 5322, Internet Message Format, Resnick, October 2008.

RFC 5890, Request for Comments: 5890, Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework. J. Klensin. August 2010.

RFC 5952, Request for Comments: 5952, A Recommendation for IPv6 Address Text Representation. S. Kawamura, et al. August 2010.

RFC 6818, Updates to the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. January 2013.

RFC 6960, Request for Comments: 6960, X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP. S. Santesson, et al. June 2013.

RFC 6962, Request for Comments: 6962, Certificate Transparency. B. Laurie, et al. June 2013.

RFC 7482, Request for Comments: 7482, Registration Data Access Protocol (RDAP) Query Format. A. Newton, et al. March 2015.

RFC 7301, Request for Comments: 7301, Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension. Friedl, Popov, Langley, Stephan, July 2014.

RFC 7538, Request For Comments: 7538, The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect). J. Reschke. April 2015.

RFC 8398, Request for Comments: 8398, Internationalized Email Addresses in X.509 Certificates, MAY 2018. A. Melnikov, et al. May 2018.

RFC 8499, Request for Comments: 8499, DNS Terminology. P. Hoffman, et al. January 2019.

RFC 8555, Request for Comments: 8555, Automatic Certificate Management Environment (ACME). Barnes, Hoffman-Andrews, McCarney, Kasten, March 2019

RFC 8659, Request for Comments: 8659, DNS Certification Authority Authorization (CAA) Resource Record, Hallam-Baker, Stradling, Hoffman-Andrews, November 2019.

RFC 8737, Request for Comments: 8737, Automated Certificate Management Environment (ACME) TLS Application-Layer Protocol Negotiation (ALPN) Challenge Extension. Shoemaker, February 2020.

RFC 8738, Request for Comments: 8738, Automated Certificate Management Environment (ACME) IP Identifier Validation Extension. R.B.Shoemaker, Ed. February 2020.

RFC 8954, Request for Comments: 8954, Online Certificate Status Protocol (OCSP) Nonce Extension. M. Sahni, Ed. November 2020.

WebTrust for Certification Authorities, SSL Baseline with Network Security, available at https://www.cpacanada.ca/en/business-and-accounting-resources/audit-and-assurance/overview-of-webtrust-services/principles-and-criteria.

X.509, Recommendation ITU-T X.509 (08/2005) | ISO/IEC 9594-8:2005, Information technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks.

Appendix B: Document History

Version Date Change owner Note
6.0 2025-07-22 CA Policy Authority Combined CPS 5.22 & TLS CP 4.11 into one document.