The Google Public Key Infrastructure ("Google PKI"), has been established by Google Trust Services, LLC ("Google"), to enable reliable and secure identity authentication, and to facilitate the preservation of confidentiality and integrity of data in electronic transactions.
This certificate policy (CP) is the principal statement of policy governing the CAs within the Google PKI. It sets forth the business, legal, and technical requirements for approving, issuing, managing, using, revoking, and renewing, Google Certificates and providing associated trust services for all Participants. These requirements protect the security and integrity of the Google PKI and comprise a single set of rules that apply consistently to all CAs therein, so as to provide assurance of uniform trust throughout it.
This CP conforms to the Certificate Policy and Certification Practices Framework of the Internet Engineering Task Force as defined in (IETF) RFC 3647 and adopts the CA/Browser Forum's Requirements for the Issuance and Management of Publicly-Trusted Certificates (BR) in their current version.
All CAs subject to this CP SHALL give effect to the BR in their current version and indicate their applicability in their CPS. In the event of any inconsistency between this CP and the BR, the BR takes precedence.
Google has reserved the following Object Identifiers (OIDs) for its issuance policies.
| Policy Identifier | Google Trust Services Object Identifier (GTS OID) |
|---|---|
| This Certificate Policy (CP) | 1.3.6.1.4.1.11129.2.5.3 |
| signedHTTPExchanges | 1.3.6.1.4.1.11129.2.5.3.1 |
| clientAuthentication* | 1.3.6.1.4.1.11129.2.5.3.2 |
| documentSigning* | 1.3.6.1.4.1.11129.2.5.3.3 |
| S/MIME | 1.3.6.1.4.1.11129.2.5.3.4 |
* These Policy Identifiers are reserved for future issuance and will be described in subsequent versions of this CP.
In addition to the GTS OIDs, all Certificates that comply with the BR shall include one of the following CA/B Forum Policy Identifiers:
All end entity certificates shall include at least one of the GTS OIDs. They may include any number of OIDs that are specified under the GTS reserved policy OID arc of {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) or the CA/Browser Forum's reserved policy OID arc of {joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-policies(1)} (2.23.140.1).
Subject to the restrictions in Section 7.1.6 of this CP, CAs may issue certificates containing the "anyPolicy" identifier (2.5.29.32.0).
This CP applies to all CAs that issue certificates asserting a GTS OID. By including a GTS OID, the CA asserts that the certificate was issued and is managed in accordance with this CP and the relevant CPS.
See Appendix.
| Compliance | Section(s) | Summary Description (See Full Text for Details) |
|---|---|---|
| 2017-09-01 | 3.2.2.8 | CAs MUST check and process CAA records |
| 2018-03-01 | 6.3.2 | Certificates issued MUST have a Validity Period no greater than 825 days |
| 2018-03-01 | 4.2.1 | re-use of validation information limited to 825 days |
| 2018-05-31 | 2.2 | CP and CPS must follow RFC 3647 format |
| 2018-10-14 | 4.9.1. | Revocation timelines extended |
| 2019-01-15 | 7.1.4.2.1 | All certificates containing an underscore character in any dNSName entry and having a validity period of more than 30 days MUST be revoked prior to January 15, 2019 |
| 2019-05-01 | 7.1.4.2.1 | underscore characters MUST NOT be present in dNSName entries |
| 2019-06-01 | 3.2.2.4.3 | Phone Contact with Domain Contact retired as validation method |
| 2019-08-01 | 3.2.2.5 | CAs shall maintain record of IP validation method used |
| 2019-08-01 | 3.2.2.5.4 | CAs may no longer use "Any Other Method" for certificate validations |
| 2020-06-03 | 3.2.2.4.6 | CAs may not perform certificate validations using method 3.2.2.4.6 |
| 2020-07-24 | 3.2.2.8, 6.3.2, 7.1.2.3 | Signed HTTP Exchanges Certificate Profile added |
| 2020-08-01 | 8.6 | Audit Reports for periods on-or-after 2020-08-01 MUST be structured as defined. |
| 2020-09-01 | 6.3.2 | Certificates issued SHOULD NOT have a Validity Period greater than 397 days and MUST NOT have a Validity Period greater than 398 days. |
| 2020-09-30 | 4.9.10 | OCSP responses MUST conform to the validity period requirements specified. |
| 2020-09-30 | 7.1.4.1 | Subject and Issuer Names for all possible certification paths MUST be byte-for-byte identical. |
| 2020-09-30 | 7.1.6.4 | Subscriber Certificates MUST include a CA/Browser Forum Reserved Policy Identifier in the Certificate Policies extension. |
| 2020-09-30 | 7.2 and 7.3 | All OCSP and CRL responses for Subordinate CA Certificates MUST include a meaningful reason code. |
| 2023-07-15 | 4.9.1.1 and 7.2.2 | SC-61: New CRL entries MUST have a revocation reason code. |
| 2023-09-15 | 7 | CAs MUST use the updated Certificate Profiles passed in Version 2.0.0. |
Google Trust Services LLC is the Certification Authority (CA) authorized to issue public key certificates within the Google PKI.
With the exception of sections 3.2.2.4 and 3.2.2.5, the CA MAY delegate the performance of all, or any part, of Section 3.2 requirements to a Delegated Third Party, provided that the process as a whole fulfills all of the requirements of Section 3.2.
Before the CA authorizes a Delegated Third Party to perform a delegated function, the CA SHALL contractually require the Delegated Third Party to:
The CA MAY designate an Enterprise RA to verify certificate requests from the Enterprise RA's own organization. The CA SHALL NOT accept certificate requests authorized by an Enterprise RA unless the following requirements are satisfied:
The CA SHALL impose these limitations as a contractual requirement on the Enterprise RA and monitor compliance by the Enterprise RA.
No stipulation.
A Relying Party is any individual or entity that acts in reliance on a Google Certificate to verify a digital signature and/or decrypt an encrypted document or message.
Not applicable.
The primary goal of this Policy is to enable efficient and secure electronic communication, while addressing Relying Parties' concerns about the trustworthiness of Certificates.
No stipulation.
Google Trust Services LLC
1600 Amphitheatre Parkway
Mountain View, CA 94043
Google Trust Services LLC
CA Policy Authority
1600 Amphitheatre Parkway
Mountain View, CA 94043
contact@pki.goog
To notify Google of a CA service outage or a security issue including a suspected Private Key compromise, Certificate misuse, or other types of fraud, compromise, misuse, inappropriate conduct, or any other matter related to Certificates, please contact us using the contact form at https://pki.goog/ or send an email to contact@pki.goog.
If you request a Certificate revocation, please add "Revocation request" and the domain name, IP address or certificate serial number into the subject line of your email.
The Google CA Policy Authority determines the suitability of CPSs published in response to this CP.
Approvals of this CP and any amendments thereof are made by the Policy Authority. Amendments SHALL be made by publishing a new version of this CP at https://pki.goog/repository/. In the event Google decides to make significant changes to this CP, notification of such changes will be posted at https://pki.goog/.
A new version of the CP will become effective fifteen (15) days after such posting, and will supersede all previous versions and will be binding on all Participants in the Google PKI from that point forward.
This CP and associated documents are available from the Repository at https://pki.goog/repository/.
See Appendix A.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in these Requirements SHALL be interpreted in accordance with RFC 2119.
By convention, this document 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.
The CA SHALL develop, implement, enforce, and annually update a Certification Practice Statement that describes in detail how the CA implements the latest version of these Requirements.
The CA SHALL make revocation information for Subordinate Certificates and Subscriber Certificates available in accordance with this Policy.
The CA SHALL publicly disclose its Certificate Policy and/or Certification Practice Statement through an appropriate and readily accessible online means that is available on a 24x7 basis. The CA SHALL publicly disclose its CA business practices to the extent required by the CA's selected audit scheme (see Section 8.4).
The Certificate Policy and Certification Practice Statement is structured in accordance with RFC 3647 and includes all material required by RFC 3647.
Section 4.2 of a CA's Certificate Policy and/or Certification Practice Statement SHALL state the CA's policy or practice on processing CAA Records for Fully-Qualified Domain Names; that policy shall be consistent with this CP. It shall clearly specify the set of Issuer Domain Names that the CA recognizes in CAA "issue" or "issuewild" records as permitting it to issue. The CA SHALL log all actions taken, if any, consistent with its processing practice.
The CA SHALL publicly give effect to the CAB/Forum's Baseline Requirements for the Issuance and Management of Publicly Trusted Certificates and represent that it will adhere to the latest published version. The CA MAY fulfill this requirement by incorporating these Requirements directly into its Certificate Policy and/or Certification Practice Statements or by incorporating them by reference.
The CA SHALL host test Web pages that allow Application Software Suppliers to test their software with Subscriber Certificates that chain up to each publicly trusted Root Certificate. At a minimum, the CA SHALL host separate Web pages using Subscriber Certificates that are (i) valid, (ii) revoked, and (iii) expired.
The CA SHALL develop, implement, enforce, and annually update a Certificate Policy and/or Certification Practice Statement that describes in detail how the CA implements the latest version of these Requirements. The CA SHALL indicate conformance with this requirement by incrementing the version number and adding a dated changelog entry, even if no other changes are made to the document.
The CA shall make its Repository publicly available in a read-only manner.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
If the Applicant requests a Certificate that will contain Subject Identity Information comprised only of the countryName field, then the CA SHALL verify the country associated with the Subject using a verification process meeting the requirements of Section 3.2.2.3 and that is described in the CA's Certificate Policy and/or Certification Practice Statement.
If the Applicant requests a Certificate that will contain the countryName field and other Subject Identity Information, then the CA SHALL verify the identity of the Applicant, and the authenticity of the Applicant Representative's certificate request using a verification process meeting the requirements of this Section 3.2.2.1 and that is described in the CA's Certificate Policy and/or Certification Practice Statement. The CA SHALL inspect any document relied upon under this Section for alteration or falsification.
If the Subject Identity Information is to include the name or address of an organization, the CA SHALL verify the identity and address of the organization and that the address is the Applicant's address of existence or operation. The CA SHALL verify the identity and address of the Applicant using documentation provided by, or through communication with, at least one of the following:
The CA may use the same documentation or communication described in 1 through 4 above to verify both the Applicant's identity and address.
Alternatively, the CA may verify the address of the Applicant (but not the identity of the Applicant) using a utility bill, bank statement, credit card statement, government-issued tax document, or other form of identification that the CA determines to be reliable.
If the Subject Identity Information is to include a DBA or tradename, the CA SHALL verify the Applicant's right to use the DBA/tradename using at least one of the following:
If the subject:countryName field is present, then the CA SHALL verify the country associated with the Subject using one of the following: (a) the IP Address range assignment by country for either (i) the web site's IP address, as indicated by the DNS record for the web site or (ii) the Applicant's IP address; (b) the ccTLD of the requested Domain Name; (c) information provided by the Domain Name Registrar; or (d) a method identified in Section 3.2.2.1. The CA SHOULD implement a process to screen proxy servers in order to prevent reliance upon IP addresses assigned in countries other than where the Applicant is actually located.
This section defines the permitted processes and procedures for validating the Applicant's ownership or control of the domain.
The CA SHALL confirm that prior to issuance, the CA has validated each Fully-Qualified Domain Name (FQDN) listed in the Certificate using at least one of the methods listed below.
CAs may not issue certificates for FQDNs that contain "onion" as the rightmost label.
Completed validations of Applicant authority may be valid for the issuance of multiple Certificates over time. In all cases, the validation must have been initiated within the time period specified in the relevant requirement (such as Section 4.2.1 of this document) prior to Certificate issuance. For purposes of domain validation, the term Applicant includes the Applicant's Parent Company, Subsidiary Company, or Affiliate.
CAs SHALL maintain a record of which domain validation method, including relevant BR version number, they used to validate every domain.
Note: FQDNs may be listed in Subscriber Certificates using dNSNames in the subjectAltName extension or in Subordinate CA Certificates via dNSNames in permittedSubtrees within the Name Constraints extension.
This method has been retired and MUST NOT be used. Prior validations using this method and validation data gathered according to this method SHALL NOT be used to issue certificates
Confirming the Applicant's control over the FQDN by sending a Random Value via email, fax, SMS, or postal mail and then receiving a confirming response utilizing the Random Value. The Random Value MUST be sent to an email address, fax/SMS number, or postal mail address identified as a Domain Contact.
Each email, fax, SMS, or postal mail MAY confirm control of multiple Authorization Domain Names.
The CA MAY send the email, fax, SMS, or postal mail identified under this section to more than one recipient provided that every recipient is identified by the Domain Name Registrar as representing the Domain Name Registrant for every FQDN being verified using the email, fax, SMS, or postal mail.
The Random Value SHALL be unique in each email, fax, SMS, or postal mail.
The CA MAY resend the email, fax, SMS, or postal mail in its entirety, including re-use of the Random Value, provided that the communication's entire contents and recipient(s) remain unchanged.
The Random Value SHALL remain valid for use in a confirming response for no more than 30 days from its creation. The CPS MAY specify a shorter validity period for Random Values, in which case the CA MUST follow its CPS.
Note: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the Domain Labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names.
This method has been retired and MUST NOT be used. Prior validations using this method and validation data gathered according to this method SHALL NOT be used to issue certificates
Confirm the Applicant's control over the FQDN by
Each email MAY confirm control of multiple FQDNs, provided the Authorization Domain Name used in the email is an Authorization Domain Name for each FQDN being confirmed
The Random Value SHALL be unique in each email.
The email MAY be re-sent in its entirety, including the re-use of the Random Value, provided that its entire contents and recipient SHALL remain unchanged.
The Random Value SHALL remain valid for use in a confirming response for no more than 30 days from its creation. The CPS MAY specify a shorter validity period for Random Values.
Note: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names.
This method has been retired and MUST NOT be used. Prior validations using this method and validation data gathered according to this method SHALL NOT be used to issue certificates.
This method has been retired and MUST NOT be used. Prior validations using this method and validation data gathered according to this method SHALL NOT be used to issue certificates.
Confirming the Applicant's control over the FQDN by confirming the presence of a Random Value or Request Token for either in a DNS CNAME, TXT or CAA record for either 1) an Authorization Domain Name; or 2) an Authorization Domain Name that is prefixed with a label that begins with an underscore character.
If a Random Value is used, the CA SHALL provide a Random Value unique to the Certificate request and SHALL not use the Random Value after (i) 30 days or (ii) if the Applicant submitted the Certificate request, the time frame permitted for reuse of validated information relevant to the Certificate (such as in Section 4.2.1 of this document).
Note: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the Domain Labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names.
Confirming the Applicant's control over the FQDN by confirming that the Applicant controls an IP address returned from a DNS lookup for A or AAAA records for the FQDN in accordance with section 3.2.2.5.
Note: Once the FQDN has been validated using this method, the CA MAY NOT also issue Certificates for other FQDNs that end with all the Domain Labels of the validated FQDN unless the CA performs a separate validation for that FQDN using an authorized method. This method is NOT suitable for validating Wildcard Domain Names.
This method has been retired and MUST NOT be used. Prior validations using this method and validation data gathered according to this method SHALL NOT be used to issue certificates
This method has been retired and MUST NOT be used. Prior validations using this method and validation data gathered according to this method SHALL NOT be used to issue certificates.
This method has been retired and MUST NOT be used.
Confirming the Applicant's control over the FQDN by validating the Applicant is the Domain Contact. This method may only be used if the CA is also the Domain Name Registrar, or an Affiliate of the Registrar, of the Base Domain Name.
Note: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names.
Confirming the Applicant's control over the FQDN by sending a Random Value via email and then receiving a confirming response utilizing the Random Value. The Random Value MUST be sent to a DNS CAA Email Contact. The relevant CAA Resource Record Set MUST be found using the search algorithm defined in RFC 8659, Section 3.
Each email MAY confirm control of multiple FQDNs, provided that each email address is a DNS CAA Email Contact for each Authorization Domain Name being validated. The same email MAY be sent to multiple recipients as long as all recipients are DNS CAA Email Contacts for each Authorization Domain Name being validated.
The Random Value SHALL be unique in each email. The email MAY be re-sent in its entirety, including the re-use of the Random Value, provided that its entire contents and recipient(s) SHALL remain unchanged. The Random Value SHALL remain valid for use in a confirming response for no more than 30 days from its creation. The CPS MAY specify a shorter validity period for Random Values.
Note: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the Domain Labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names.
Confirming the Applicant's control over the FQDN by sending a Random Value via email and then receiving a confirming response utilizing the Random Value. The Random Value MUST be sent to a DNS TXT Record Email Contact for the Authorization Domain Name selected to validate the FQDN.
Each email MAY confirm control of multiple FQDNs, provided that each email address is DNS TXT Record Email Contact for each Authorization Domain Name being validated. The same email MAY be sent to multiple recipients as long as all recipients are DNS TXT Record Email Contacts for each Authorization Domain Name being validated. The Random Value SHALL be unique in each email. The email MAY be re-sent in its entirety, including the reuse of the Random Value, provided that its entire contents and recipient(s) SHALL remain unchanged.
The Random Value SHALL remain valid for use in a confirming response for no more than 30 days from its creation. The CPS MAY specify a shorter validity period for Random Values.
Note: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the Domain Labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names.
Confirm the Applicant's control over the FQDN by calling the Domain Contact's phone number and obtain a confirming response to validate the ADN. Each phone call MAY confirm control of multiple ADNs provided that the same Domain Contact phone number is listed for each ADN being verified and they provide a confirming response for each ADN.
In the event that someone other than a Domain Contact is reached, the CA MAY request to be transferred to the Domain Contact.
In the event of reaching voicemail, the CA may leave the Random Value and the ADN(s) being validated. The Random Value MUST be returned to the CA to approve the request.
The Random Value SHALL remain valid for use in a confirming response for no more than 30 days from its creation. The CPS MAY specify a shorter validity period for Random Values.
Note: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the Domain Labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names.
Confirm the Applicant's control over the FQDN by calling the DNS TXT Record Phone Contact's phone number and obtain a confirming response to validate the ADN. Each phone call MAY confirm control of multiple ADNs provided that the same DNS TXT Record Phone Contact phone number is listed for each ADN being verified and they provide a confirming response for each ADN.
The CA MUST NOT knowingly be transferred or request to be transferred as this phone number has been specifically listed for the purposes of Domain Validation.
In the event of reaching voicemail, the CA may leave the Random Value and the ADN(s) being validated. The Random Value MUST be returned to the CA to approve the request.
The Random Value SHALL remain valid for use in a confirming response for no more than 30 days from its creation. The CPS MAY specify a shorter validity period for Random Values.
Note: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the Domain Labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names.
Confirm the Applicant's control over the FQDN by calling the DNS CAA Phone Contact's phone number and obtain a confirming response to validate the ADN. Each phone call MAY confirm control of multiple ADNs provided that the same DNS CAA Phone Contact phone number is listed for each ADN being verified and they provide a confirming response for each ADN. The relevant CAA Resource Record Set MUST be found using the search algorithm defined in RFC 8659 Section 3.
The CA MUST NOT be transferred or request to be transferred as this phone number has been specifically listed for the purposes of Domain Validation.
In the event of reaching voicemail, the CA may leave the Random Value and the ADN(s) being validated. The Random Value MUST be returned to the CA to approve the request.
The Random Value SHALL remain valid for use in a confirming response for no more than 30 days from its creation. The CPS MAY specify a shorter validity period for Random Values.
Note: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the Domain Labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names.
Confirming the Applicant's control over the FQDN by verifying that the Request Token or Random Value is contained in the contents of a file.
The file containing the Request Token or Random Number:
If the CA follows redirects the following apply:
If a Random Value is used, then:
Note: The CA MUST NOT issue Certificates for other FQDNs that end with all the labels of the validated FQDN unless the CA performs a separate validation for that FQDN using an authorized method. This method is NOT suitable for validating Wildcard Domain Names.
Confirming the Applicant's control over a FQDN by validating domain control of the FQDN using the ACME HTTP Challenge method defined in section 8.3 of RFC 8555. The following are additive requirements to RFC 8555.
The CA MUST receive a successful HTTP response from the request (meaning a 2xx HTTP status code must be received).
The token (as defined in RFC 8555, section 8.3) MUST NOT be used for more than 30 days from its creation. The CPS MAY specify a shorter validity period for Random Values, in which case the CA MUST follow its CPS.
If the CA follows redirects:
Note: The CA MUST NOT issue Certificates for other FQDNs that end with all the labels of the validated FQDN unless the CA performs a separate validation for that FQDN using an authorized method. This method is NOT suitable for validating Wildcard Domain Names.
Confirming the Applicant's control over a FQDN by validating domain control of the FQDN by negotiating a new application layer protocol using the TLS Application-Layer Protocol Negotiation (ALPN) Extension [RFC7301] as defined in RFC 8737. The following are additive requirements to RFC 8737.
The token (as defined in RFC 8737, section 3) MUST NOT be used for more than 30 days from its creation. The CPS MAY specify a shorter validity period for the token, in which case the CA MUST follow its CPS.
Note: Once the FQDN has been validated using this method, the CA MAY NOT also issue Certificates for other FQDNs that end with all the Domain Labels of the validated FQDN unless the CA performs a separate validation for that FQDN using an authorized method. This method is NOT suitable for validating Wildcard Domain Names.
This section defines the permitted processes and procedures for validating the Applicant's ownership or control of an IP Address listed in a Certificate.
The CA SHALL confirm that prior to issuance, the CA has validated each IP Address listed in the Certificate using at least one of the methods specified in this section.
Completed validations of Applicant authority may be valid for the issuance of multiple Certificates over time. In all cases, the validation must have been initiated within the time period specified in the relevant requirement (such as Section 4.2.1 of this document) prior to Certificate issuance. For purposes of IP Address validation, the term Applicant includes the Applicant's Parent Company, Subsidiary Company, or Affiliate.
After July 31, 2019, CAs SHALL maintain a record of which IP validation method, including the relevant BR version number, was used to validate every IP Address.
Confirming the Applicant's control over the requested IP Address by confirming the presence of a Request Token or Random Value contained in the content of a file or webpage in the form of a meta tag under the "/.well-known/pki-validation" directory, or another path registered with IANA for the purpose of validating control of IP Addresses, on the IP Address that is accessible by the CA via HTTP/HTTPS over an Authorized Port. The Request Token or Random Value MUST NOT appear in the request.
If a Random Value is used, the CA SHALL provide a Random Value unique to the certificate request and SHALL not use the Random Value after the longer of (i) 30 days or (ii) if the Applicant submitted the certificate request, the time frame permitted for reuse of validated information relevant to the certificate (such as in Section 4.2.1 of this document).
Confirming the Applicant's control over the IP Address by sending a Random Value via email, fax, SMS, or postal mail and then receiving a confirming response utilizing the Random Value. The Random Value MUST be sent to an email address, fax/SMS number, or postal mail address identified as an IP Address Contact.
Each email, fax, SMS, or postal mail MAY confirm control of multiple IP Addresses.
The CA MAY send the email, fax, SMS, or postal mail identified under this section to more than one recipient provided that every recipient is identified by the IP Address Registration Authority as representing the IP Address Contact for every IP Address being verified using the email, fax, SMS, or postal mail.
The Random Value SHALL be unique in each email, fax, SMS, or postal mail.
The CA MAY resend the email, fax, SMS, or postal mail in its entirety, including re-use of the Random Value, provided that the communication's entire contents and recipient(s) remain unchanged.
The Random Value SHALL remain valid for use in a confirming response for no more than 30 days from its creation. The CPS MAY specify a shorter validity period for Random Values, in which case the CA MUST follow its CPS.
Confirming the Applicant's control over the IP Address by obtaining a Domain Name associated with the IP Address through a reverse-IP lookup on the IP Address and then verifying control over the FQDN using a method permitted under Section 3.2.2.4.
Using any other method of confirmation, including variations of the methods defined in Section 3.2.2.5, provided that the CA maintains documented evidence that the method of confirmation establishes that the Applicant has control over the IP Address to at least the same level of assurance as the methods previously described in version 1.6.2 of the CA/B Forum Baseline Requirements.
CAs SHALL NOT perform validations using this method after July 31, 2019. Completed validations using this method SHALL NOT be re-used for certificate issuance after July 31, 2019. Any certificate issued prior to August 1, 2019 containing an IP Address that was validated using any method that was permitted under the prior version of this section 3.2.2.5 MAY continue to be used without revalidation until such certificate naturally expires.
Confirming the Applicant's control over the IP Address by calling the IP Address Contact's phone number and obtaining a response confirming the Applicant's request for validation of the IP Address. The CA MUST place the call to a phone number identified by the IP Address Registration Authority as the IP Address Contact. Each phone call SHALL be made to a single number.
In the event that someone other than an IP Address Contact is reached, the CA MAY request to be transferred to the IP Address Contact.
In the event of reaching voicemail, the CA may leave the Random Value and the IP Address(es) being validated.
The Random Value MUST be returned to the CA to approve the request. The Random Value SHALL remain valid for use in a confirming response for no more than 30 days from its creation. The CPS MAY specify a shorter validity period for Random Values.
Confirming the Applicant's control over the IP Address by performing the procedure documented for an "http-01" challenge in draft 04 of "ACME IP Identifier Validation Extension," available at https://tools.ietf.org/html/draft-ietf-acme-ip-04#section-4.
Confirming the Applicant's control over the IP Address by performing the procedure documented for a "tlsalpn-01" challenge in draft 04 of "ACME IP Identifier Validation Extension," available at https://tools.ietf.org/html/draft-ietf-acme-ip-04#section-4.
Before issuing a Wildcard Certificate, the CA MUST establish and follow a documented procedure that determines if the FQDN portion of any Wildcard Domain Name in the Certificate is "registry-controlled" or is a "public suffix" (e.g. "*.com", "*.co.uk", see RFC 6454 Section 8.2 for further explanation).
If the FQDN portion of any Wildcard Domain Name is "registry-controlled" or is a "public suffix", CAs MUST refuse issuance unless the Applicant proves its rightful control of the entire Domain Namespace. (e.g. CAs MUST NOT issue "*.co.uk" or "*.local", but MAY issue "*.example.com" to Example Co.).
Determination of what is "registry-controlled" versus the registerable portion of a Country Code Top-Level Domain Namespace is not standardized at the time of writing and is not a property of the DNS itself. Current best practice is to consult a "public suffix list" such as the Public Suffix List (PSL) at http://publicsuffix.org/, and to retrieve a fresh copy regularly.
If using the PSL, a CA SHOULD consult the "ICANN DOMAINS" section only, not the "PRIVATE DOMAINS" section. The PSL is updated regularly to contain new gTLDs delegated by ICANN, which are listed in the "ICANN DOMAINS" section. A CA is not prohibited from issuing a Wildcard Certificate to the Registrant of an entire gTLD, provided that control of the entire namespace is demonstrated in an appropriate way.
Prior to using any data source as a Reliable Data Source, the CA SHALL evaluate the source for its reliability, accuracy, and resistance to alteration or falsification. The CA SHOULD consider the following during its evaluation:
Databases maintained by the CA, its owner, or its affiliated companies do not qualify as a Reliable Data Source if the primary purpose of the database is to collect information for the purpose of fulfilling the validation requirements under Section 3.2.
As part of the issuance process, the CA MUST check for CAA records and follow the processing instructions found, for each dNSName in the subjectAltName extension of the certificate to be issued, as specified in RFC 8659. If the CA issues, they MUST do so within the TTL of the CAA record, or 8 hours, whichever is greater.
This stipulation does not prevent the CA from checking CAA records at any other time.
When processing CAA records, CAs MUST process the issue, issuewild, and iodef property tags as specified in RFC 8659, although they are not required to act on the contents of the iodef property tag. Additional property tags MAY be supported, but MUST NOT conflict with or supersede the mandatory property tags set out in this document. CAs MUST respect the critical flag and not issue a certificate if they encounter an unrecognized property tag with this flag set.
RFC 8659 requires that CAs "MUST NOT issue a certificate unless the CA determines that either (1) the certificate request is consistent with the applicable CAA RRset or (2) an exception specified in the relevant CP or CPS applies." For issuances conforming to these Baseline Requirements, CAs MUST NOT rely on any exceptions specified in their CP or CPS unless they are one of the following:
CAs are permitted to treat a record lookup failure as permission to issue if:
CAs MUST document potential issuances that were prevented by a CAA record in sufficient detail to provide feedback to the CAB Forum on the circumstances, and SHOULD dispatch reports of such issuance requests to the contact(s) stipulated in the CAA iodef record(s), if present. CAs are not expected to support URL schemes in the iodef record other than mailto: or https:.
If the certificate to be issued is a subscriber certificate asserting the 1.3.6.1.4.1.11129.2.5.3.1 policy identifier, the CA MUST check for the existence of the "cansignhttpexchanges" parameter having the value "yes". If a CAA record cannot be found, CAs MUST refuse issuance.
If an Applicant subject to this Section 3.2.2 is a natural person, then the CA SHALL verify the Applicant's name, Applicant's address, and the authenticity of the certificate request.
The CA SHALL verify the Applicant's name using a legible copy, which discernibly shows the Applicant's face, of at least one currently valid government-issued photo ID (passport, drivers license, military ID, national ID, or equivalent document type). The CA SHALL inspect the copy for any indication of alteration or falsification.
The CA SHALL verify the Applicant's address using a form of identification that the CA determines to be reliable, such as a government ID, utility bill, or bank or credit card statement. The CA may rely on the same government-issued ID that was used to verify the Applicant's name.
The CA SHALL verify the certificate request with the Applicant using a Reliable Method of Communication.
No stipulation.
If the Applicant for a Certificate containing Subject Identity Information is an organization, the CA SHALL use a Reliable Method of Communication to verify the authenticity of the Applicant Representative's certificate request.
The CA may use the sources listed in section 3.2.2.1 to verify the Reliable Method of Communication. Provided that the CA uses a Reliable Method of Communication, the CA may establish the authenticity of the certificate request directly with the Applicant Representative or with an authoritative source within the Applicant's organization, such as the Applicant's main business offices, corporate offices, human resource offices, information technology offices, or other department that the CA deems appropriate.
In addition, the CA SHALL establish a process that allows an Applicant to specify the individuals who may request Certificates. If an Applicant specifies, in writing, the individuals who may request a Certificate, then the CA SHALL not accept any certificate requests that are outside this specification. The CA SHALL provide an Applicant with a list of its authorized certificate requesters upon the Applicant's verified written request.
The CA SHALL disclose all Cross-Certified Subordinate CA Certificates that identify the CA as the Subject, provided that the CA arranged for or accepted the establishment of the trust relationship (i.e. the Cross-Certified Subordinate CA Certificate at issue).
No stipulation.
No stipulation.
No stipulation.
In accordance with Section 5.5.2, the CA SHALL maintain an internal database of all previously revoked Certificates and previously rejected certificate requests due to suspected phishing or other fraudulent usage or concerns. The CA SHALL use this information to identify subsequent suspicious certificate requests.
Prior to the issuance of a Certificate, the CA SHALL obtain the following documentation from the Applicant:
The CA SHOULD obtain any additional documentation the CA determines necessary to meet these Requirements.
Prior to the issuance of a Certificate, the CA SHALL obtain from the Applicant a certificate request in a form prescribed by the CA and that complies with these Requirements. One certificate request MAY suffice for multiple Certificates to be issued to the same Applicant, subject to the aging and updating requirement in Section 4.2.1, provided that each Certificate is supported by a valid, current certificate request signed by the appropriate Applicant Representative on behalf of the Applicant. The certificate request MAY be made, submitted and/or signed electronically.
The certificate request MUST contain a request from, or on behalf of, the Applicant for the issuance of a Certificate, and a certification by, or on behalf of, the Applicant that all of the information contained therein is correct.
The certificate request MAY include all factual information about the Applicant to be included in the Certificate, and such additional information as is necessary for the CA to obtain from the Applicant in order to comply with this Policy and/or the CA's Certification Practice Statement. In cases where the certificate request does not contain all the necessary information about the Applicant, the CA SHALL obtain the remaining information from the Applicant or, having obtained it from a reliable, independent, third-party data source, confirm it with the Applicant. The CA SHALL establish and follow a documented procedure for verifying all data requested for inclusion in the Certificate by the Applicant.
Applicant information MUST include, but not be limited to, at least one Fully-Qualified Domain Name or IP address to be included in the Certificate's subjectAltName extension.
Section 6.3.2 limits the validity period of Subscriber Certificates. The CA MAY use the documents and data provided in Section 3.2 to verify certificate information, or may reuse previous validations themselves, provided that the CA obtained the data or document from a source specified under Section 3.2 or completed the validation itself no more than 825 days prior to issuing the Certificate. For validation of Domain Names and IP Addresses according to Section 3.2.2.4 and 3.2.2.5, any reused data, document, or completed validation MUST be obtained no more than 398 days prior to issuing the Certificate.
In no case may a prior validation be reused if any data or document used in the prior validation was obtained more than the maximum time permitted for reuse of the data or document prior to issuing the Certificate.
After the change to any validation method specified in the Baseline Requirements or EV Guidelines, a CA may continue to reuse validation data or documents collected prior to the change, or the validation itself, for the period stated in this Section 4.2.1 unless otherwise specifically provided in a ballot.
The CA SHALL develop, maintain, and implement documented procedures that identify and require additional verification activity for High Risk Certificate Requests prior to the Certificate's approval, as reasonably necessary to ensure that such requests are properly verified under these Requirements.
If a Delegated Third Party fulfills any of the CA's obligations under this section , the CA SHALL verify that the process used by the Delegated Third Party to identify and further verify High Risk Certificate Requests provides at least the same level of assurance as the CA's own processes.
CAs SHALL NOT issue certificates containing Internal Names or Reserved IP Addresses (as such names cannot be validated according to Section 3.2.2.4 or Section 3.2.2.5).
No stipulation.
Certificate issuance by the Root CA SHALL require an individual authorized by the CA (i.e. the CA system operator, system officer, or PKI administrator) to deliberately issue a direct command in order for the Root CA to perform a certificate signing operation.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
See Section 9.6.3, provisions 2. and 4.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
The CA SHALL revoke a Certificate within 24 hours and use the corresponding CRLReason (see Section 7.2.2) if one or more of the following occurs:
The CA SHOULD revoke a certificate within 24 hours and MUST revoke a Certificate within 5 days and use the corresponding CRLReason if one or more of the following occurs:
The Issuing CA SHALL revoke a Subordinate CA Certificate within seven (7) days if one or more of the following occurs:
The Subscriber, RA, or Issuing CA can initiate revocation. Additionally, Subscribers, Relying Parties, Application Software Suppliers, and other third parties may submit Certificate Problem Reports informing the issuing CA of reasonable cause to revoke the certificate.
The CA SHALL provide a process for Subscribers to request revocation of their own Certificates. The process MUST be described in the CA's Certificate Policy or Certification Practice Statement.
The CA SHALL maintain a continuous 24x7 ability to accept and respond to revocation requests and Certificate Problem Reports.
The CA SHALL provide Subscribers, Relying Parties, Application Software Suppliers, and other third parties with clear instructions for reporting suspected Private Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, inappropriate conduct, or any other matter related to Certificates. The CA SHALL publicly disclose the instructions through a readily accessible online means and in section 1.5.2 of their CPS.
No stipulation.
Within 24 hours after receiving a Certificate Problem Report, the CA SHALL 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.
After reviewing the facts and circumstances, the CA SHALL work with the Subscriber and any entity reporting the Certificate Problem Report or other revocation-related notice to establish whether or not the certificate will be revoked, and if so, a date which the CA will revoke the certificate.
The period from receipt of the Certificate Problem Report or revocation-related notice to published revocation MUST NOT exceed the time frame set forth in Section 4.9.1.1. The date selected by the CA SHOULD consider the following criteria:
No stipulation.
Note: Following certificate issuance, a certificate may be revoked for any reason stated in Section 4.9. Therefore, relying parties should check the revocation status of all certificates that contain a CDP or OCSP pointer.
For the status of Subscriber Certificates:
If the CA publishes a CRL, then the CA SHALL update and reissue CRLs at least once every seven days, and the value of the nextUpdate field MUST NOT be more than ten days beyond the value of the thisUpdate field.
For the status of Subordinate CA Certificates:
The CA SHALL update and reissue CRLs at least (i) once every twelve months and (ii) within 24 hours after revoking a Subordinate CA Certificate. The value of the nextUpdate field MUST NOT be more than twelve months beyond the value of the thisUpdate field.
No stipulation.
OCSP responses MUST conform to RFC6960 and/or RFC5019. OCSP responses MUST either:
In the latter case, the OCSP signing Certificate MUST contain an extension of type id-pkix-ocsp-nocheck, as defined by RFC6960.
OCSP responders operated by the CA SHALL support the HTTP GET method, as described in RFC 6960 and/or RFC 5019.
The validity interval of an OCSP response is the difference in time between the thisUpdate and nextUpdate field, inclusive. For purposes of computing differences, a difference of 3,600 seconds shall be equal to one hour, and a difference of 86,400 seconds shall be equal to one day, ignoring leap-seconds.
For the status of Subscriber Certificates:
For the status of Subordinate CA Certificates:
If the OCSP responder receives a request for the status of a certificate serial number that is "unused", then the responder SHOULD NOT respond with a "good" status.
If the OCSP responder is for a CA that is not Technically Constrained in line with Section 7.1.2.3 or Section 7.1.2.5, the responder MUST NOT respond with a "good" status for such requests.
The CA SHOULD monitor the OCSP responder for requests for "unused" serial numbers as part of its security response procedures.
The OCSP responder MAY provide definitive responses about "reserved" certificate serial numbers, as if there was a corresponding Certificate that matches the Precertificate [RFC6962].
A certificate serial number within an OCSP request is one of the following three options:
No Stipulation.
See Section 4.9.1
The Repository MUST NOT include entries that indicate that a Certificate is suspended.
Not applicable.
Not applicable.
Not applicable.
Revocation entries on a CRL or OCSP Response MUST NOT be removed until after the Expiry Date of the revoked Certificate.
The CA SHALL operate and maintain its CRL and OCSP capability with resources sufficient to provide a response time of ten seconds or less under normal operating conditions.
The CA SHALL maintain an online 24x7 Repository that application software can use to automatically check the current status of all unexpired Certificates issued by the CA.
The CA SHALL maintain a continuous 24x7 ability to respond internally to a high-priority Certificate Problem Report, and where appropriate, forward such a complaint to law enforcement authorities, and/or revoke a Certificate that is the subject of such a complaint.
No stipulation.
No stipulation.
No stipulation.
Not applicable.
The CA SHALL develop, implement, and maintain a comprehensive security program designed to:
The Certificate Management Process MUST include:
The CA's security program MUST include an annual Risk Assessment that:
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;
Assesses the likelihood and potential damage of these threats, taking into consideration the sensitivity of the Certificate Data and Certificate Management Processes; and
Assesses the sufficiency of the policies, procedures, information systems, technology, and other arrangements that the CA has in place to counter such threats.
Based on the Risk Assessment, the CA SHALL develop, implement, and maintain a security plan consisting of security procedures, measures, and products designed to achieve the objectives set forth above and to manage and control the risks identified during the Risk Assessment, commensurate with the sensitivity of the Certificate Data and Certificate Management Processes. The security plan MUST include administrative, organizational, technical, and physical safeguards appropriate to the sensitivity of the Certificate Data and Certificate Management Processes. The security plan MUST also take into account then-available technology and the cost of implementing the specific measures, and SHALL implement a reasonable level of security appropriate to the harm that might result from a breach of security and the nature of the data to be protected.
The CA infrastructure SHALL be located and operated from secure Google facilities. Detailed security procedures MUST be in place and followed that prohibit unauthorized access and entry into the areas of the facilities in which CA systems reside.
No stipulation.
The CA SHALL have in place appropriate physical security controls to restrict access to all hardware and software used for providing CA Services. Access to such hardware and software SHALL be limited to those personnel performing in a trusted role and two-person access SHALL be enforced.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
The Private Key SHALL be backed up, stored, and recovered only by personnel in trusted roles using, at least, dual control in a physically secured environment.
No stipulation.
No stipulation.
Prior to the engagement of any person in the Certificate Management Process, whether as an employee, agent, or an independent contractor of the CA, the CA SHALL verify the identity and trustworthiness of such person.
No stipulation.
The CA SHALL provide all personnel performing information verification duties with skills-training that covers basic Public Key Infrastructure knowledge, authentication and vetting policies and procedures (including the CA's Certificate Policy and/or Certification Practice Statement), common threats to the information verification process (including phishing and other social engineering tactics), and these Requirements.
The CA SHALL maintain records of such training and ensure that personnel entrusted with Validation Specialist duties maintain a skill level that enables them to perform such duties satisfactorily.
The CA SHALL document that each Validation Specialist possesses the skills required by a task before allowing the Validation Specialist to perform that task.
The CA SHALL require all Validation Specialists to pass an examination provided by the CA on the information verification requirements outlined in these Requirements.
All personnel in Trusted roles SHALL maintain skill levels consistent with the CA's training and performance programs.
No stipulation.
No stipulation.
The CA SHALL verify that the Delegated Third Party's personnel involved in the issuance of a Certificate meet the training and skills requirements of Section 5.3.3 and the document retention and event logging requirements of Section 5.4.1.
No stipulation.
The CA and each Delegated Third Party SHALL record details of the actions taken to process a certificate request and to issue a Certificate, including all information generated and documentation received in connection with the certificate request; the time and date; and the personnel involved. The CA SHALL make these records available to its Qualified Auditor as proof of the CA's compliance with these Requirements.
The CA SHALL record at least the following events:
CA certificate and key lifecycle events, including:
Subscriber Certificate lifecycle management events, including:
Security events, including:
Log entries MUST include the following elements:
No stipulation.
The CA SHALL retain, for at least two years:
CA certificate and key lifecycle management event records (as set forth in Section 5.4.1 (1)) after the later occurrence of:
Subscriber Certificate lifecycle management event records (as set forth in Section 5.4.1 (2)) after the revocation or expiration of the Subscriber Certificate;
Any security event records (as set forth in Section 5.4.1 (3)) after the event occurred.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
Additionally, the CA's security program MUST include an annual Risk Assessment that:
No stipulation.
Archived audit logs (as set forth in Section 5.5.1 SHALL be retained for a period of at least two (2) years from their record creation timestamp or inline with Section 5.4.3, whichever is longer.
Additionally, the CA and each Delegated Third Party SHALL retain, for at least two (2) years:
All archived documentation related to the security of Certificate Systems, Certificate Management Systems, Root CA Systems and Delegated Third Party Systems (as set forth in Section 5.5.1); and
All archived documentation relating to the verification, issuance, and revocation of certificate requests and Certificates (as set forth in Section 5.5.1) after the later occurrence of: 1. such records and documentation were last relied upon in the verification, issuance, or revocation of certificate requests and Certificates; or 2. the expiration of the Subscriber Certificates relying upon such records and documentation
No stipulation.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
CA organizations shall have an Incident Response Plan and a Disaster Recovery Plan.
The CA SHALL document a business continuity and disaster recovery procedure designed to notify and reasonably protect Application Software Suppliers, Subscribers, and Relying Parties in the event of a disaster, security compromise, or business failure. The CA is not required to publicly disclose its business continuity plans but SHALL make its business continuity plan and security plans available to the CA's auditors upon request. The CA SHALL annually test, review, and update these procedures.
The business continuity plan MUST include:
No stipulation.
No stipulation.
No stipulation.
No stipulation.
For CA Key Pairs that are either (i) used as a CA Key Pair for a Root Certificate or (ii) used as a CA Key Pair for a Subordinate CA Certificate, where the Subordinate CA is not the operator of the Root CA or an Affiliate of the Root CA, the CA SHALL:
For other CA Key Pairs that are for the operator of the Root CA or an Affiliate of the Root CA, the CA SHOULD:
In all cases, the CA SHALL:
generate the CA Key Pair in a physically secured environment as described in the CA's Certificate Policy and/or Certification Practice Statement;
generate the CA Key Pair using personnel in Trusted Roles under the principles of multiple person control and split knowledge;
generate the CA Key Pair within cryptographic modules meeting the applicable technical and business requirements as disclosed in the CA's Certification Practice Statement;
log its CA Key Pair generation activities; and
maintain effective controls to provide reasonable assurance that the Private Key was generated and protected in conformance with the procedures described in its Certification Practice Statement and (if applicable) its Key Generation Script.
No stipulation.
The CA SHALL reject a certificate request if one or more of the following conditions are met:
If the Subscriber Certificate will contain an extKeyUsage extension containing either the values id-kp-serverAuth [RFC5280] or anyExtendedKeyUsage [RFC5280], the CA SHALL NOT generate a Key Pair on behalf of a Subscriber, and SHALL NOT accept a certificate request using a Key Pair previously generated by the CA.
Parties other than the Subscriber SHALL NOT archive the Subscriber Private Key without authorization by the Subscriber.
If the CA or any of its designated RAs become aware that a Subscriber's Private Key has been communicated to an unauthorized person or an organization not affiliated with the Subscriber, then the CA SHALL revoke all certificates that include the Public Key corresponding to the communicated Private Key.
No stipulation.
No stipulation.
For RSA key pairs the CA SHALL:
For ECDSA key pairs, the CA SHALL:
No other algorithms or key sizes are permitted.
RSA: The CA SHALL confirm that the value of the public exponent is an odd number equal to 3 or more. Additionally, the public exponent SHOULD be in the range between 2^16+1 and 2^256-1. The modulus SHOULD also have the following characteristics: an odd number, not the power of a prime, and have no factors smaller than 752. [Source: Section 5.3.3, NIST SP 800-89]
ECDSA: The CA SHOULD confirm the validity of all keys using either the ECC Full Public Key Validation Routine or the ECC Partial Public Key Validation Routine. [Source: Sections 5.6.2.3.2 and 5.6.2.3.3, respectively, of NIST SP 800-56A: Revision 2]
Private Keys corresponding to Root Certificates MUST NOT be used to sign Certificates except in the following cases:
The CA SHALL implement physical and logical safeguards to prevent unauthorized certificate issuance. Protection of the Private Key outside the validated system or device specified above MUST consist of physical security, encryption, or a combination of both, implemented in a manner that prevents disclosure of the Private Key.
The CA SHALL encrypt its Private Key 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.
No stipulation.
No stipulation.
No stipulation.
See Section 5.2.2
Parties other than the Subordinate CA SHALL NOT archive the Subordinate CA Private Keys without authorization by the Subordinate CA.
If the Issuing CA generated the Private Key on behalf of the Subordinate CA, then the Issuing CA SHALL encrypt the Private Key for transport to the Subordinate CA. If the Issuing CA becomes aware that a Subordinate CA's Private Key has been communicated to an unauthorized person or an organization not affiliated with the Subordinate CA, then the Issuing CA SHALL revoke all certificates that include the Public Key corresponding to the communicated Private Key.
The CA SHALL protect its Private Key in a system or device that has been validated as meeting at least FIPS 140-2 level 3, FIPS 140-3 level 3, or an appropriate Common Criteria Protection Profile or Security Target, EAL 4 (or higher), which includes requirements to protect the Private Key and other assets against known threats.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
Subscriber Certificates issued on or after 1 September 2020 SHOULD NOT have a Validity Period greater than 397 days and MUST NOT have a Validity Period greater than 398 days. Subscriber Certificates issued after 1 March 2018, but prior to 1 September 2020, MUST NOT have a Validity Period greater than 825 days.
For the purpose of calculations, a day is measured as 86,400 seconds. Any amount of time greater than this, including fractional seconds and/or leap seconds, shall represent an additional day. For this reason, Subscriber Certificates SHOULD NOT be issued for the maximum permissible time by default, in order to account for such adjustments.
No stipulation.
No stipulation.
No stipulation.
The CA SHALL enforce multi-factor authentication for all accounts capable of directly causing certificate issuance.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
The CA SHALL meet the technical requirements set forth in Section 2.2 – Publication of Information, Section 6.1.5 – Key Sizes, and Section 6.1.6 – Public Key Parameters Generation and Quality Checking.
Prior to 2023-09-15, the CA SHALL issue Certificates in accordance with the profile specified in this CP or the profile specified in version 1.8.6 of the Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates. Effective 2023-09-15, the CA SHALL issue Certificates in accordance with the profile specified in these Requirements.
Certificates MUST be of type X.509 v3.
This section specifies the additional requirements for Certificate content and extensions for Certificates.
All certificates that the CA issues MUST comply with one of the following certificate profiles, which incorporate, and are 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. Examine RFC 5280, Appendix B for further issues to be aware of.
CA Certificates
Section 7.1.2.1 - Root CA Certificate Profile
Subordinate CA Certificates
Cross Certificates
Technically Constrained CA Certificates
Section 7.1.2.6 - TLS Subordinate CA Certificate Profile
Section 7.1.2.7 - Subscriber (End-Entity) Certificate Profile
Section 7.1.2.8 - OCSP Responder Certificate Profile
Section 7.1.2.9 - Precertificate Profile
| field | Description |
|---|---|
tbsCertificate | |
version | Must be v3(2) |
serialNumber | MUST be 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 | Encoded value MUST be byte-for-byte identical to |
| : : the encoded subject : | |
validity | See Section 7.1.2.1.1 |
subject | See Section 7.1.2.10.2 |
subjectPublicKeyInfo | See Section 7.1.3.1 |
issuerUniqueID | MUST NOT be present |
subjectUniqueID | MUST NOT be present |
extensions | See Section 7.1.2.1.2 |
signatureAlgorithm | Encoded value MUST be byte-for-byte identical to |
: : the tbsCertificate.signature. : | |
signature |
| Field | Minimum | Maximum |
notBefore | One day prior to the time of | The time of signing |
| : : signing : : | ||
notAfter | 2922 days (approx. 8 years) | 9132 days (approx. 25 years) |
| Extension | Presence | Critical | Description |
authorityKeyIdentifier | RECOMMENDED | N | See Section |
| : : : : 7.1.2.1.3 : | |||
basicConstraints | MUST | Y | See Section |
| : : : : 7.1.2.1.4 : | |||
keyUsage | MUST | Y | See Section |
| : : : : 7.1.2.10.7 : | |||
subjectKeyIdentifier | MUST | N | See Section |
| : : : : 7.1.2.11.4 : | |||
extKeyUsage | MUST NOT | N | - |
certificatePolicies | NOT RECOMMENDED | N | See Section |
| : : : : 7.1.2.10.5 : | |||
| Signed Certificate | MAY | N | See Section |
| : Timestamp List : : : 7.1.2.11.3 : | |||
| Any other extension | NOT RECOMMENDED | - | See Section |
| : : : : 7.1.2.11.5 : |
| Field | Description |
keyIdentifier | MUST be present. MUST be identical to the |
: : subjectKeyIdentifier field. : | |
authorityCertIssuer | MUST NOT be present |
authorityCertSerialNumber | MUST NOT be present |
| |
:-----------------: | :--------------:
Field | Description
cA | MUST be set TRUE
pathLenConstraint | NOT RECOMMENDED
This Certificate Profile MAY be used when issuing a CA Certificate using the same Subject Name and Subject Public Key Information as one or more existing CA Certificate(s), whether a Root CA Certificate or Subordinate CA Certificate.
Before issuing a Cross-Certified Subordinate CA, the Issuing CA MUST confirm that the existing CA Certificate(s) are subject to these Baseline Requirements and were issued in compliance with the then-current version of the Baseline Requirements at time of issuance.
| Field | Description |
tbsCertificate | |
version | MUST be v3(2) |
serialNumber | MUST be 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 | MUST be byte-for-byte identical to the |
: : subject field of the Issuing CA. See Section : | |
| : : 7.1.4.1 : | |
validity | See Section 7.1.2.2.1 |
subject | See Section 7.1.2.2.2 |
subjectPublicKeyInfo | See Section 7.1.3.1 |
issuerUniqueID | MUST NOT be present |
subjectUniqueID | MUST NOT be present |
extensions | See Section 7.1.2.2.3 |
signatureAlgorithm | Encoded value MUST be byte-for-byte identical |
: : to the tbsCertificate.signature. : | |
signature |
| Field | Minimum | Maximum |
notBefore | The earlier of one day prior to the time | The time of signing |
: : of signing or the earliest notBefore : : | ||
| : : date of the existing CA Certificate(s) : : | ||
notAfter | The time of signing | Unspecified |
The subject MUST comply with the requirements of Section 7.1.4, or, if the existing CA Certificate was issued in compliance with the then-current version of the Baseline Requirements, the encoded subject name MUST be byte-for-byte identical to the encoded subject name of the existing CA Certificate.
| Extension | Presence | Critical | Description |
authorityKeyIdentifier | MUST | N | See Section |
| : : : : 7.1.2.11.1 : | |||
basicConstraints | MUST | Y | See Section |
| : : : : 7.1.2.10.4 : | |||
certificatePolicies | MUST | N | See Section |
| : : : : 7.1.2.10.5 : | |||
crlDistributionPoints | MUST | N | See Section |
| : : : : 7.1.2.11.2 : | |||
keyUsage | MUST | Y | See Section |
| : : : : 7.1.2.10.7 : | |||
subjectKeyIdentifier | MUST | N | See Section |
| : : : : 7.1.2.11.4 : | |||
authorityInformationAccess | SHOULD | N | See Section |
| : : : : 7.1.2.10.3 : | |||
nameConstraints | MAY | See Section | |
| : : : : 7.1.2.10.8 : | |||
| Signed Certificate Timestamp | MAY | N | See Section |
| : List : : : 7.1.2.11.3 : | |||
| Any other extension | NOT | - | See Section |
| : : RECOMMENDED : : 7.1.2.11.5 : |
In addition to the above, extKeyUsage extension requirements vary based on the relationship between the Issuer and Subject organizations represented in the CrossCertificate.
The extKeyUsage extension MAY be “unrestricted” as described in the following table if:
the organizationName represented in the Issuer and Subject names of the corresponding certificate are either:
the corresponding CA represented by the Subject of the Cross-Certificate is operated by the same organization as the Issuing CA or an Affiliate of the Issuing CA organization.
Cross-Certified Subordinate CA with Unrestricted EKU
| | | |
:-----------: | :----------: | :----------: | :------------------:
Extension | Presence | Critical | Description
extKeyUsage | SHOULD | N | See Section 7.1.2.2.
3 See Section 7.1.2.10.8 for further requirements, including regarding criticality of this extension.
4 While RFC 5280, Section 4.2.1.12 notes that this extension will generally only appear within end-entity certificates, these Requirements make use of this extension to further protect relying parties by limiting the scope of CA Certificates, as implemented by a number of Application Software Suppliers.
In all other cases, the extKeyUsage extension MUST be “restricted” as described in the following table:
Cross-Certified Subordinate CA with Restricted EKU
| | | |
:-----------: | :----------: | :----------: | :-------------------:
Extension | Presence | Critical | Description
extKeyUsage | MUST | N | See Section 7.1.2.2.5
Table: Unrestricted Extended Key Usage Purposes (Affiliated Cross-Certified CA)
| Key Purpose | Description |
anyExtendedKeyUsage | The special extended key usage to indicate there are |
| : : no restrictions applied. If present, this MUST be : | |
| : : the only key usage present. : | |
| Any other value | CAs MUST NOT include any other key usage with the |
: : anyExtendedKeyUsage key usage present. : |
Alternatively, if the Issuing CA does not use this form, then the Extended Key Usage extension, if present, MUST be encoded as specified in Section 7.1.2.2.5
Table: Restricted TLS Cross-Certified Subordinate CA Extended Key Usage Purposes (i.e., for restricted Cross-Certified Subordinate CAs issuing TLS certificates directly or transitively)
| |
:---------------------: | :------------------:
Key Purpose | Description
id-kp-serverAuth | MUST be present.
id-kp-clientAuth | MAY be present.
id-kp-emailProtection | MUST NOT be present.
id-kp-codeSigning | MUST NOT be present.
id-kp-timeStamping | MUST NOT be present.
anyExtendedKeyUsage | MUST NOT be present.
Any other value | NOT RECOMMENDED.
Restricted Non-TLS Cross-Certified Subordinate CA Extended Key Usage Purposes (i.e., for restricted CrossCertified Subordinate CAs not issuing TLS certificates directly or transitively)
| |
:-------------------: | :------------------:
Key Purpose | Description
id-kp-serverAuth | MUST NOT be present.
anyExtendedKeyUsage | MUST NOT be present.
Any other value | MAY be present.
Each included Extended Key Usage key usage purpose:
CAs MUST NOT include additional key usage purposes unless the CA is aware of a reason for including the key usage purpose in the Certificate.
7.1.2.3 Technically Constrained Non-TLS Subordinate CA Certificate Profile
This Certificate Profile MAY be used when issuing a CA Certificate that will be considered Technically Constrained, and which will not be used to issue TLS certificates directly or transitively.
| Field | Description |
tbsCertificate | |
version | MUST be v3(2) |
serialNumber | MUST be 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 | MUST be byte-for-byte identical to the |
: : subject field of the Issuing CA. See Section : | |
| : : 7.1.4.1 : | |
validity | See Section 7.1.2.10.1 |
subject | See Section 7.1.2.10.2 |
subjectPublicKeyInfo | See Section 7.1.3.1 |
issuerUniqueID | MUST NOT be present |
subjectUniqueID | MUST NOT be present |
extensions | See Section 7.1.2.3.1 |
signatureAlgorithm | Encoded value MUST be byte-for-byte identical |
: : to the tbsCertificate.signature. : | |
signature |
| Extension | Presence | Critical | Description |
authorityKeyIdentifier | MUST | N | See Section |
| : : : : 7.1.2.11.1 : | |||
basicConstraints | MUST | Y | See Section |
| : : : : 7.1.2.10.4 : | |||
crlDistributionPoints | MUST | N | See Section |
| : : : : 7.1.2.11.2 : | |||
keyUsage | MUST | Y | See Section |
| : : : : 7.1.2.10.7 : | |||
subjectKeyIdentifier | MUST | N | See Section |
| : : : : 7.1.2.11.4 : | |||
extKeyUsage | MUST | N | See Section |
| : : : : 7.1.2.3.3 : | |||
authorityInformationAccess | SHOULD | N | See Section |
| : : : : 7.1.2.10.3 : | |||
certificatePolicies | MAY | N | See Section |
| : : : : 7.1.2.3.2 : | |||
nameConstraints | MAY | See Section | |
| : : : : 7.1.2.10.8 : | |||
| Signed Certificate Timestamp | MAY | N | See Section |
| : List : : : 7.1.2.11.3 : | |||
| Any other extension | NOT | - | See Section |
| : : RECOMMENDED : : 7.1.2.11.5 : |
If present, the Certificate Policies extension MUST be formatted as one of the two tables below:
No Policy Restrictions (Affiliated CA)
| Field | Presence | Contents |
policyIdentifier | MUST | When the Issuing CA wishes to express |
| : : : that there are no policy : | ||
| : : : restrictions, the Subordinate CA MUST : | ||
| : : : be an Affiliate of the Issuing CA. : | ||
| : : : The Certificate Policies extension : | ||
| : : : MUST contain only a single : | ||
: : : PolicyInformation value, which MUST : | ||
: : : contain the anyPolicy Policy : | ||
| : : : Identifier. : | ||
anyPolicy | MUST | |
policyQualifiers | NOT RECOMMENDED | If present, MUST contain only |
: : : permitted policyQualifiers from the : | ||
| : : : table below. : |
Table: Policy Restricted
| Field | Presence | Contents |
policyIdentifier | MUST | One of the following policy |
| : : : identifiers: : | ||
| A Reserved Certificate | MUST NOT | |
| : Policy Identifier : : : | ||
anyPolicy | MUST NOT | The anyPolicy Policy |
| : : : Identifier MUST NOT be : | ||
| : : : present. : | ||
| Any other identifier | MAY | If present, MUST be |
| : : : documented by the CA in its : | ||
| : : : Certificate Policy and/or : | ||
| : : : Certification Practice : | ||
| : : : Statement. : | ||
policyQualifiers | NOT RECOMMENDED | If present, MUST contain only |
: : : permitted policyQualifiers : | ||
| : : : from the table below. : |
Table: Permitted policyQualifiers
| Qualifier ID | Presence | Field Type | Contents |
id-qt-cps (OID: | MAY | IA5String | The HTTP or HTTPS URL |
| : 1.3.6.1.5.5.7.2.1) : : : for the Issuing CA's : | |||
| : : : : Certificate Policies, : | |||
| : : : : Certification Practice : | |||
| : : : : Statement, Relying : | |||
| : : : : Party Agreement, or : | |||
| : : : : other pointer to online : | |||
| : : : : policy information : | |||
| : : : : provided by the Issuing : | |||
| : : : : CA. : | |||
| Any other | MUST NOT | - | - |
| : qualifier : : : : |
The Issuing CA MUST verify that the Subordinate CA Certificate is authorized to issue certificates for each included extended key usage purpose. Multiple, independent key purposes (e.g. id-kp-timeStamping and id-kp-codeSigning) are NOT RECOMMENDED.
| | |
:--------------------------------: | :---------------------: | :----------:
Key Purpose | OID | Presence
id-kp-serverAuth | 1.3.6.1.5.5.7.3.1 | MUST NOT
id-kp-OCSPSigning | 1.3.6.1.5.5.7.3.9 | MUST NOT
anyExtendedKeyUsage | 2.5.29.37.0 | MUST NOT
Precertificate Signing Certificate | 1.3.6.1.4.1.11129.2.4.4 | MUST NOT
Any other value | - | MAY
7.1.2.4 Technically Constrained Precertificate Signing CA Certificate Profile
This Certificate Profile MUST be used when issuing a CA Certificate that will be used as a Precertificate Signing CA, as described in RFC 6962, Section 3.1. If a CA Certificate conforms to this profile, it is considered Technically Constrained.
A Precertificate Signing CA MUST only be used to sign Precertificates, as defined in Section 7.1.2.9. When a Precertificate Signing CA issues a Precertificate, it shall be interpreted as if the Issuing CA of the Precertificate Signing CA has issued a Certificate with a matching tbsCertificate of the Precertificate, after applying the modifications specified in RFC 6962, Section 3.2.
As noted in RFC 6962, Section 3.2, the signature field of a Precertificate is not altered as part of these modifications. As such, the Precertificate Signing CA MUST use the same signature algorithm as the Issuing CA when issuing Precertificates, and, correspondingly, MUST use a public key of the same public key algorithm as the Issuing CA, although MAY use a different CA Key Pair.
| Field | Description |
tbsCertificate | |
version | MUST be v3(2) |
serialNumber | MUST be 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 | MUST be byte-for-byte identical to the |
: : subject field of the Issuing CA. See Section : | |
| : : 7.1.4.1 : | |
validity | See Section 7.1.2.10.1 |
subject | See Section 7.1.2.10.2 |
subjectPublicKeyInfo | The algorithm identifier MUST be byte-for-byte |
| : : identical to the algorithm identifier of the : | |
: : subjectPublicKeyInfo field of the Issuing CA. : | |
| : : See Section 7.1.3.1 : | |
issuerUniqueID | MUST NOT be present |
subjectUniqueID | MUST NOT be present |
extensions | See Section 7.1.2.4.1 |
signatureAlgorithm | Encoded value MUST be byte-for-byte identical |
: : to the tbsCertificate.signature. : | |
signature |
| Extension | Presence | Critical | Description |
authorityKeyIdentifier | MUST | N | See Section |
| : : : : 7.1.2.11.1 : | |||
basicConstraints | MUST | Y | See Section |
| : : : : 7.1.2.10.4 : | |||
certificatePolicies | MUST | N | See Section |
| : : : : 7.1.2.10.5 : | |||
crlDistributionPoints | MUST | N | See Section |
| : : : : 7.1.2.11.2 : | |||
keyUsage | MUST | Y | See Section |
| : : : : 7.1.2.10.7 : | |||
subjectKeyIdentifier | MUST | N | See Section |
| : : : : 7.1.2.11.4 : | |||
extKeyUsage | MUST | N | See Section |
| : : : : 7.1.2.4.2 : | |||
authorityInformationAccess | SHOULD | N | See Section |
| : : : : 7.1.2.10.3 : | |||
nameConstraints | MAY | See Section | |
| : : : : 7.1.2.10.8 : | |||
| Signed Certificate Timestamp | MAY | N | See Section |
| : List : : : 7.1.2.11.3 : | |||
| Any other extension | NOT | - | See Section |
| : : RECOMMENDED : : 7.1.2.11.5 : |
| | |
:--------------------------------: | :---------------------: | :----------: Key Purpose | OID | Presence Precertificate Signing Certificate | 1.3.6.1.4.1.11129.2.4.4 | MUST Any other value | - | MUST NOT
7.1.2.5 Technically Constrained TLS Subordinate CA Certificate Profile
This Certificate Profile MAY be used when issuing a CA Certificate that will be considered Technically Constrained, and which will be used to issue TLS certificates directly or transitively.
| Field | Description |
tbsCertificate | |
version | MUST be v3(2) |
serialNumber | MUST be 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 | MUST be byte-for-byte identical to the |
: : subject field of the Issuing CA. See Section : | |
| : : 7.1.4.1 : | |
validity | See Section 7.1.2.10.1 |
subject | See Section 7.1.2.10.2 |
subjectPublicKeyInfo | See Section 7.1.3.1 |
issuerUniqueID | MUST NOT be present |
subjectUniqueID | MUST NOT be present |
extensions | See Section 7.1.2.5.1 |
signatureAlgorithm | Encoded value MUST be byte-for-byte identical |
: : to the tbsCertificate.signature. : | |
signature |
| Extension | Presence | Critical | Description |
authorityKeyIdentifier | MUST | N | See Section |
| : : : : 7.1.2.11.1 : | |||
basicConstraints | MUST | Y | See Section |
| : : : : 7.1.2.10.4 : | |||
certificatePolicies | MUST | N | See Section |
| : : : : 7.1.2.10.5 : | |||
crlDistributionPoints | MUST | N | See Section |
| : : : : 7.1.2.11.2 : | |||
keyUsage | MUST | Y | See Section |
| : : : : 7.1.2.10.7 : | |||
subjectKeyIdentifier | MUST | N | See Section |
| : : : : 7.1.2.11.4 : | |||
extKeyUsage | MUST | N | See Section |
| : : : : 7.1.2.10.6 : | |||
nameConstraints | MUST | See Section | |
| : : : : 7.1.2.5.2 : | |||
authorityInformationAccess | SHOULD | N | See Section |
| : : : : 7.1.2.10.3 : | |||
| Signed Certificate Timestamp | MAY | N | See Section |
| : List : : : 7.1.2.11.3 : | |||
| Any other extension | NOT | - | See Section |
| : : RECOMMENDED : : 7.1.2.11.5 : |
For a TLS Subordinate CA to be Technically Constrained, Name Constraints extension MUST be encoded as follows. As an explicit exception from RFC 5280, this extension SHOULD be marked critical, but MAY be marked non-critical if compatibility with certain legacy applications that do not support Name Constraints is necessary.
Table: nameConstraints requirements
| Field | Description |
permittedSubtrees | The permittedSubtrees MUST contain at least one |
: : GeneralSubtree for both of the dNSName and : | |
: : iPAddress GeneralName name types, UNLESS the : | |
: : specified GeneralName name type appears within the : | |
: : excludedSubtrees to exclude all names of that name : | |
: : type. Additionally, the permittedSubtrees MUST : | |
: : contain at least one GeneralSubtree of the : | |
: : directoryName GeneralName name type. : | |
GeneralSubtree | The requirements for a GeneralSubtree that appears |
: : within a permittedSubtrees. : | |
base | See following table. |
minimum | MUST NOT be present. |
maximum | MUST NOT be present. |
excludedSubtrees | The excludedSubtrees MUST contain at least one |
: : GeneralSubtree for each of the dNSName and : | |
: : iPAddress GeneralName name types, unless there is : | |
| : : an instance present of that name type in the : | |
: : permittedSubtrees. The directoryName name type is : | |
| : : NOT RECOMMENDED. : | |
GeneralSubtree | The requirements for a GeneralSubtree that appears |
: : within a permittedSubtrees. : | |
base | See following table. |
minimum | MUST NOT be present. |
maximum | MUST NOT be present. |
The following table contains the requirements for the GeneralName that appears within the base of a GeneralSubtree in either the permittedSubtrees or excludedSubtrees.
Table: GeneralName requirements for the base field
| | | | |
:-------------: | :-------------: | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | :------------------------------------------------------------------------------------------------------------------------------------------------------: | :-:
Name Type | Presence | Permitted Subtrees | Excluded Subtrees | Entire Namespace Exclusion
dNSName | MUST | The CA MUST confirm that the Applicant has registered the dNSName or has been authorized by the domain registrant to act on the registrant's behalf. See Section 3.2.2.4. | If at least one dNSName instance is present in the permittedSubtrees, the CA MAY indicate one or more subordinate domains to be excluded. | If no dNSName instance is present in the permittedSubtrees, then the CA MUST include a zero-length dNSName to indicate no domain names are permitted.
iPAddress | MUST | The CA MUST confirm that the Applicant has been assigned the iPAddress range or has been authorized by the assigner to act on the asignee's behalf. See Section 3.2.2.5. | If at least one iPAddress instance is present in the permittedSubtrees, the CA MAY indicate one or more subdivisions of those ranges to be excluded. | If no IPv4 iPAddress is present in the permittedSubtrees, the CA MUST include an iPAddress of 8 zero octets, indicating the IPv4 range of 0.0.0.0/0 being excluded. If no IPv6 iPAddress is present in the permittedSubtrees, the CA MUST include an iPAddress of 32 zero octets, indicating the IPv6 range of ::0/0 being excluded.
directoryName | MUST | The CA MUST confirm the Applicant's and/or Subsidiary's name attributes such that all certificates issued will comply with the relevant Certificate Profile (see Section 7.1.2), including Name Forms (See Section 7.1.4). | It is NOT RECOMMENDED to include values within excludedSubtrees. | The CA MUST include a value within permittedSubtrees, and as such, this does not apply. See the Excluded Subtrees requirements for more.
otherName | NOT RECOMMENDED | See below | See below | See below
Any other value | MUST NOT | - | - | -
Any otherName, if present:
1. MUST apply in the context of the public Internet, unless: a. the type-id falls within an OID arc for which the Applicant demonstrates ownership, or, b. the Applicant can otherwise demonstrate the right to assert the data in a public context.
2. MUST NOT include semantics that will mislead the Relying Party about certificate information verified by the CA.
3. MUST be DER encoded according to the relevant ASN.1 module defining the otherName type-id and value.
CAs SHALL NOT include additional names unless the CA is aware of a reason for including the data in the Certificate.
| Field | Description |
tbsCertificate | |
version | MUST be v3(2) |
serialNumber | MUST be 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 | MUST be byte-for-byte identical to the |
: : subject field of the Issuing CA. See Section : | |
| : : 7.1.4.1 : | |
validity | See Section 7.1.2.10.1 |
subject | See Section 7.1.2.10.2 |
subjectPublicKeyInfo | See Section 7.1.3.1 |
issuerUniqueID | MUST NOT be present |
subjectUniqueID | MUST NOT be present |
extensions | See Section 7.1.2.6.1 |
signatureAlgorithm | Encoded value MUST be byte-for-byte identical |
: : to the tbsCertificate.signature. : | |
signature |
| Extension | Presence | Critical | Description |
authorityKeyIdentifier | MUST | N | See Section |
| : : : : 7.1.2.11.1 : | |||
basicConstraints | MUST | Y | See Section |
| : : : : 7.1.2.10.4 : | |||
certificatePolicies | MUST | N | See Section |
| : : : : 7.1.2.10.5 : | |||
crlDistributionPoints | MUST | N | See Section |
| : : : : 7.1.2.11.2 : | |||
keyUsage | MUST | Y | See Section |
| : : : : 7.1.2.10.7 : | |||
subjectKeyIdentifier | MUST | N | See Section |
| : : : : 7.1.2.11.4 : | |||
extKeyUsage | MUST | N | See Section |
| : : : : 7.1.2.10.6 : | |||
authorityInformationAccess | SHOULD | N | See Section |
| : : : : 7.1.2.10.3 : | |||
nameConstraints | MAY | See Section | |
| : : : : 7.1.2.10.8 : | |||
| Signed Certificate Timestamp | MAY | N | See Section |
| : List : : : 7.1.2.11.3 : | |||
| Any other extension | NOT | - | See Section |
| : : RECOMMENDED : : 7.1.2.11.5 : |
7.1.2.7 Subscriber (Server) Certificate Profile
| Field | Description |
tbsCertificate | |
version | MUST be v3(2) |
serialNumber | MUST be 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 | MUST be byte-for-byte identical to the |
: : subject field of the Issuing CA. See Section : | |
| : : 7.1.4.1 : | |
validity | |
notBefore | A value within 48 hours of the certificate |
| : : signing operation. : | |
notAfter | See Section 6.3.2 |
subject | See Section 7.1.2.7.1 |
subjectPublicKeyInfo | See Section 7.1.3.1 |
issuerUniqueID | MUST NOT be present |
subjectUniqueID | MUST NOT be present |
extensions | See Section 7.1.2.7.6 |
signatureAlgorithm | Encoded value MUST be byte-for-byte identical |
: : to the tbsCertificate.signature. : | |
signature |
There are four types of Subscriber Certificates that may be issued, which vary based on the amount of Subject Information that is included. Each of these certificate types shares a common profile, with three exceptions: the subject name fields that may occur, how those fields are validated, and the contents of the certificatePolicies extension.
| |
:-------------------------: | :-------------------: Type | Description Domain Validated (DV) | See Section 7.1.2.7.2 Individual Validated (IV) | See Section 7.1.2.7.3 Organization Validated (OV) | See Section 7.1.2.7.4 Extended Validation (EV) | See Section 7.1.2.7.5
Note: Although each Subscriber Certificate type varies in Subject Information, all Certificates provide the same level of assurance of the device identity (domain name and/or IP address).
For a Subscriber Certificate to be Domain Validated, it MUST meet the following profile:
| Field | Requirements |
subject | See following table. |
certificatePolicies | MUST be present. MUST assert the Reserved |
: : Certificate Policy Identifier of 2.23.140.1.2.1 as : | |
: : a policyIdentifier. See Section 7.1.2.7.9 : | |
| All other extensions | See Section 7.1.2.7.6 |
All subject names MUST be encoded as specified in Section 7.1.4.
The following table details the acceptable AttributeTypes that may appear within the type field of an AttributeTypeAndValue, as well as the contents permitted within the value field.
Domain Validated subject Attributes
| Attribute Name | Presence | Value | Verification |
countryName | MAY | The two-letter ISO | Section 3.2.2.3 |
| : : : 3166-1 country : : | |||
| : : : code for the : : | |||
| : : : country associated : : | |||
| : : : with the Subject. : : | |||
commonName | NOT RECOMMENDED | If present, MUST | |
| : : : contain a value : : | |||
| : : : derived from the : : | |||
: : : subjectAltName : : | |||
| : : : extension : : | |||
| : : : according to : : | |||
| : : : Section 7.1.4.3 : : | |||
| Any other | MUST NOT | - | - |
| : attribute : : : : |
For a Subscriber Certificate to be Individual Validated, it MUST meet the following profile:
| Field | Requirements |
subject | See following table. |
certificatePolicies | MUST be present. MUST assert the Reserved |
: : Certificate Policy Identifier of 2.23.140.1.2.3 as : | |
: : a policyIdentifier. See Section 7.1.2.7.9 : | |
| All other extensions | See Section 7.1.2.7.6 |
All subject names MUST be encoded as specified in Section 7.1.4
The following table details the acceptable AttributeTypes that may appear within the type field of an AttributeTypeAndValue, as well as the contents permitted within the value field.
Individual Validated subject Attributes
| | | |
:----------------------: | :-------------: | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | :-:
Attribute Name | Presence | Value | Verification
countryName | MUST | The two-letter ISO 3166-1 country code for the country associated with the Subject. If a Country is not represented by an official ISO 3166-1 country code, the CA MUST specify the ISO 3166-1 user-assigned code of XX, indicating that an official ISO 3166-1 alpha-2 code has not been assigned. | Section 3.2.3
stateOrProvinceName | MUST / MAY | MUST be present if localityName is absent, MAY be present otherwise. If present, MUST contain the Subject's state or province information. | Section 3.2.3
localityName | MUST / MAY | MUST be present if stateOrProvinceName is absent, MAY be present otherwise. If present, MUST contain the Subject's locality information. | Section 3.2.3
postalCode | NOT RECOMMENDED | If present, MUST contain the Subject's zip or postal information. | Section 3.2.3
streetAddress | NOT RECOMMENDED | If present, MUST contain the Subject's street address information. Multiple instances MAY be present. | Section 3.2.3
organizationName | NOT RECOMMENDED | If present, MUST contain the Subject's name or DBA. | Section 3.2.3
surname | MUST | The Subject's surname. | Section 3.2.3
givenName | MUST | The Subject's given name. | Section 3.2.3
organizationalUnitName | MUST NOT | - | -
commonName | NOT RECOMMENDED | If present, MUST contain a value derived from the subjectAltName extension according to Section 7.1.4.3 |
Any other attribute | NOT RECOMMENDED | - | See Section 7.1.4.4
In addition, subject Attributes MUST NOT contain only metadata such as ‘.’, ‘-’, and ’ ’ (i.e. space) characters, and/or any other indication that the value is absent, incomplete, or not applicable.
For a Subscriber Certificate to be Organization Validated, it MUST meet the following profile:
| Field | Requirements |
subject | See following table. |
certificatePolicies | MUST be present. MUST assert the Reserved |
: : Certificate Policy Identifier of 2.23.140.1.2.2 as : | |
: : a policyIdentifier. See Section 7.1.2.7.9 : | |
| All other extensions | See Section 7.1.2.7.6 |
All subject names MUST be encoded as specified in Section 7.1.4
The following table details the acceptable AttributeTypes that may appear within the type field of an AttributeTypeAndValue, as well as the contents permitted within the value field.
Organization Validated subject Attributes
| | | |
:----------------------: | :-------------: | :-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | :-:
Attribute Name | Presence | Value | Verification
domainComponent | MAY | If present, this field MUST contain a Domain Label from a Domain Name. The domainComponent fields for the Domain Name MUST be in a single ordered sequence containing all Domain Labels from the Domain Name. The Domain Labels MUST be encoded in the reverse order to the on-wire representation of domain names in the DNS protocol, so that the Domain Label closest to the root is encoded first. Multiple instances MAY be present. | [Section 3.2]
countryName | MUST | The two-letter ISO 3166-1 country code for the country associated with the Subject. If a Country is not represented by an official ISO 3166-1 country code, the CA MUST specify the ISO 3166-1 user-assigned code of XX, indicating that an official ISO 3166-1 alpha-2 code has not been assigned. | Section 3.2.2.1
stateOrProvinceName | MUST / MAY | MUST be present if localityName is absent, MAY be present otherwise. If present, MUST contain the Subject's state or province information. | Section 3.2.2.1
localityName | MUST / MAY | MUST be present if stateOrProvinceName is absent, MAY be present otherwise. If present, MUST contain the Subject's locality information. | Section 3.2.2.1
postalCode | NOT RECOMMENDED | If present, MUST contain the Subject's zip or postal information. | Section 3.2.2.1
streetAddress | NOT RECOMMENDED | If present, MUST contain the Subject's street address information. Multiple instances MAY be present. | Section 3.2.2.1
organizationName | MUST | The Subject's name or DBA. The CA MAY include information in this field that differs slightly from the verified name, such as common variations or abbreviations, provided that the CA documents the difference and any abbreviations used are locally accepted abbreviations; e.g. if the official record shows "Company Name Incorporated", the CA MAY use "Company Name Inc." or "Company Name". | Section 3.2.2.2
surname | MUST NOT | - | -
givenName | MUST NOT | - | -
organizationalUnitName | MUST NOT | - | -
commonName | NOT RECOMMENDED | If present, MUST contain a value derived from the subjectAltName extension according to Section 7.1.4.3md#7143-subscriber-certificate-common-name-attribute). |
Any other attribute | NOT RECOMMENDED | - | See Section 7.1.4.4
In addition, subject Attributes MUST NOT contain only metadata such as ‘.’, ‘-’, and ’ ’ (i.e. space) characters, and/or any other indication that the value is absent, incomplete, or not applicable.
| Extension | Presence | Critical | Description |
authorityInformationAccess | MUST | N | See Section |
| : : : : 7.1.2.7.7 : | |||
authorityKeyIdentifier | MUST | N | See Section |
| : : : : 7.1.2.11.1 : | |||
certificatePolicies | MUST | N | See Section |
| : : : : 7.1.2.7.9 : | |||
extKeyUsage | MUST | N | See Section |
| : : : : 7.1.2.7.10 : | |||
subjectAltName | MUST | * | See Section |
| : : : : 7.1.2.7.12 : | |||
nameConstraints | MUST NOT | - | - |
keyUsage | SHOULD | Y | See Section |
| : : : : 7.1.2.7.11 : | |||
basicConstraints | MAY | Y | See Section |
| : : : : 7.1.2.7.8 : | |||
crlDistributionPoints | MAY | N | See Section |
| : : : : 7.1.2.11.2 : | |||
| Signed Certificate Timestamp | MAY | N | See Section |
| : List : : : 7.1.2.11.3 : | |||
subjectKeyIdentifier | NOT | N | See Section |
| : : RECOMMENDED : : 7.1.2.11.4 : | |||
| Any other extension | NOT | - | See Section |
| : : RECOMMENDED : : 7.1.2.11.5 : |
Note: whether or not the subjectAltName extension should be marked Critical depends on the contents of the Certificate’s subject field, as detailed in Section 7.1.2.7.12.
The AuthorityInfoAccessSyntax MUST contain one or more AccessDescriptions. Each AccessDescription MUST only contain a permitted accessMethod, as detailed below, and each accessLocation MUST be encoded as the specified GeneralName type.
The AuthorityInfoAccessSyntax MAY contain multiple AccessDescriptions with the same accessMethod, if permitted for that accessMethod. When multiple AccessDescriptions are present with the same accessMethod, each accessLocation MUST be unique, and each AccessDescription MUST be ordered in priority for that accessMethod, with the most-preferred accessLocation being the first AccessDescription. No ordering requirements are given for AccessDescriptions that contain different accessMethods, provided that previous requirement is satisfied.
| | | | | |
:---------------: | :----------------: | :-------------------------: | :----------: | :---------: | :-:
Access Method | OID | Access Location | Presence | Maximum | Description
id-ad-ocsp | 1.3.6.1.5.5.7.48.1 | uniformResourceIdentifier | MUST | * | A HTTP URL of the Issuing CA's OCSP responder.
id-ad-caIssuers | 1.3.6.1.5.5.7.48.2 | uniformResourceIdentifier | SHOULD | * | A HTTP URL of the Issuing CA's certificate.
Any other value | - | - | MUST NOT | - | No other accessMethods may be used.
7.1.2.7.8 Subscriber Certificate Basic Constraints
| |
:-----------------: | :-----------------:
Field | Description
cA | MUST be FALSE
pathLenConstraint | MUST NOT be present
If present, the Certificate Policies extension MUST contain at least one PolicyInformation. Each PolicyInformation MUST match the following profile:
| Field | Presence | Contents |
policyIdentifier | MUST | One of the following policy |
| : : : identifiers: : | ||
| A Reserved Certificate | MUST | The Reserved Certificate |
| : Policy Identifier : : Policy Identifier (see : | ||
| : : : Section 7.1.6.1) associated : | ||
| : : : with the given Subscriber : | ||
| : : : Certificate type (see Section : | ||
| : : : 7.1.2.7.1) : | ||
anyPolicy | MUST NOT | The anyPolicy Policy |
| : : : Identifier MUST NOT be : | ||
| : : : present. : | ||
| Any other identifier | MAY | If present, MUST be defined |
| : : : and documented in the CA's : | ||
| : : : Certificate Policy and/or : | ||
| : : : Certification Practice : | ||
| : : : Statement. : | ||
policyQualifiers | NOT RECOMMENDED | If present, MUST contain only |
: : : permitted policyQualifiers : | ||
| : : : from the table below. : |
This Profile RECOMMENDS that the first PolicyInformation value within the Certificate Policies extension contains the Reserved Certificate Policy Identifier (see 7.1.6.1) Policies extension MUST contain exactly one Reserved Certificate Policy Identifier.
Permitted policyQualifiers
| Qualifier ID | Presence | Field Type | Contents |
id-qt-cps (OID: | MAY | IA5String | The HTTP or HTTPS URL |
| : 1.3.6.1.5.5.7.2.1) : : : for the Issuing CA's : | |||
| : : : : Certificate Policies, : | |||
| : : : : Certification Practice : | |||
| : : : : Statement, Relying : | |||
| : : : : Party Agreement, or : | |||
| : : : : other pointer to online : | |||
| : : : : policy information : | |||
| : : : : provided by the Issuing : | |||
| : : : : CA. : | |||
| Any other | MUST NOT | - | - |
| : qualifier : : : : |
| | |
:--------------------------------: | :---------------------: | :-------------:
Key Purpose | OID | Presence
id-kp-serverAuth | 1.3.6.1.5.5.7.3.1 | MUST
id-kp-clientAuth | 1.3.6.1.5.5.7.3.2 | MAY
id-kp-codeSigning | 1.3.6.1.5.5.7.3.3 | MUST NOT
id-kp-emailProtection | 1.3.6.1.5.5.7.3.4 | MUST NOT
id-kp-timeStamping | 1.3.6.1.5.5.7.3.8 | MUST NOT
id-kp-OCSPSigning | 1.3.6.1.5.5.7.3.9 | MUST NOT
anyExtendedKeyUsage | 2.5.29.37.0 | MUST NOT
Precertificate Signing Certificate | 1.3.6.1.4.1.11129.2.4.4 | MUST NOT
Any other value | - | NOT RECOMMENDED
The acceptable Key Usage values vary based on whether the Certificate’s subjectPublicKeyInfo identifies an RSA public key or an ECC public key. CAs MUST ensure the Key Usage is appropriate for the Certificate Public Key.
14 Although RFC 5280 allows PolicyInformations to appear in any order, several client implementations have implemented logic that considers the policyIdentifier that matches a given filter. As such, ensuring the Reserved Certificate Policy Identifier is the first PolicyInformation reduces the risk of interoperability challenges.
Key Usage for RSA Public Keys
| | |
:----------------: | :-----------: | :-------------:
Key Usage | Permitted | Required
digitalSignature | Y | SHOULD
nonRepudiation | N | --
keyEncipherment | Y | MAY
dataEncipherment | Y | NOT RECOMMENDED
keyAgreement | N | --
keyCertSign | N | --
cRLSign | N | --
encipherOnly | N | --
decipherOnly | N | --
Key Usage for ECC Public Keys
| | |
:----------------: | :-----------: | :-------------:
Key Usage | Permitted | Required
digitalSignature | Y | MUST
nonRepudiation | N | --
keyEncipherment | N | --
dataEncipherment | N | --
keyAgreement | Y | NOT RECOMMENDED
keyCertSign | N | --
cRLSign | N | --
encipherOnly | N | --
decipherOnly | N | --
For Subscriber Certificates, the Subject Alternative Name MUST be present and MUST contain at least one dNSName or iPAddress GeneralName. See below for further requirements about the permitted fields and their validation requirements.
If the subject field of the certificate is an empty SEQUENCE, this extension MUST be marked critical, as specified in RFC 5280, Section 4.2.1.6. Otherwise, this extension MUST NOT be marked critical.
GeneralName within a subjectAltName extension
| Name Type | Permitted | Validation |
otherName | N | - |
rfc822Name | N | - |
dNSName | Y | The entry MUST contain either |
| : : : a Fully-Qualified Domain Name : | ||
| : : : or Wildcard Domain Name that : | ||
| : : : the CA has validated in : | ||
| : : : accordance with Section : | ||
| : : : 3.2.2.4. Wildcard Domain Names : | ||
| : : : MUST be validated for : | ||
| : : : consistency with Section : | ||
| : : : 3.2.2.6. The entry MUST NOT : | ||
| : : : contain an Internal Name. The : | ||
| : : : Fully-Qualified Domain Name or : | ||
| : : : the FQDN portion of the : | ||
| : : : Wildcard Domain Name contained : | ||
| : : : in the entry MUST be composed : | ||
| : : : entirely of P-Labels or : | ||
| : : : Non-Reserved LDH Labels joined : | ||
| : : : together by a U+002E FULL STOP : | ||
| : : : (".") character. The : | ||
| : : : zero-length Domain Label : | ||
| : : : representing the root zone of : | ||
| : : : the Internet Domain Name : | ||
| : : : System MUST NOT be included : | ||
| : : : (e.g. "example.com" MUST be : | ||
| : : : encoded as "example.com" and : | ||
| : : : MUST NOT be encoded as : | ||
| : : : "example.com."). : | ||
x400Address | N | - |
directoryName | N | - |
ediPartyName | N | - |
uniformResourceIdentifier | N | - |
iPAddress | Y | The entry MUST contain the |
| : : : IPv4 or IPv6 address that the : | ||
| : : : CA has confirmed the Applicant : | ||
| : : : controls or has been granted : | ||
| : : : the right to use through a : | ||
| : : : method specified in[Section : | ||
| : : : 3.2.2.5. The entry MUST NOT : | ||
| : : : contain a Reserved IP Address. : | ||
registeredID | N | - |
If the Issuing CA does not directly sign OCSP responses, it MAY make use of an OCSP Authorized Responder, as defined by RFC 6960. The Issuing CA of the Responder MUST be the same as the Issuing CA for the Certificates it provides responses for.
| Field | Description |
tbsCertificate | |
version | MUST be v3(2) |
serialNumber | MUST be 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 | MUST be byte-for-byte identical to the |
: : subject field of the Issuing CA. See Section : | |
| : : 7.1.4.1 : | |
validity | See Section 7.1.2.8.1 |
subject | See Section 7.1.2.10.2 |
subjectPublicKeyInfo | See Section 7.1.3.1 |
issuerUniqueID | MUST NOT be present |
subjectUniqueID | MUST NOT be present |
extensions | See Section 7.1.2.8.2 |
signatureAlgorithm | Encoded value MUST be byte-for-byte identical |
: : to the tbsCertificate.signature. : | |
signature |
| | |
:---------: | :----------------------------------: | :-----------------:
Field | Minimum | Maximum
notBefore | One day prior to the time of signing | The time of signing
notAfter | The time of signing | Unspecified
| Extension | Presence | Critical | Description |
authorityKeyIdentifier | MUST | N | See Section |
| : : : : 7.1.2.11. : | |||
extKeyUsage | MUST | - | See Section |
| : : : : 7.1.2.8.5 : | |||
id-pkix-ocsp-nocheck | MUST | N | See Section |
| : : : : 7.1.2.8.6 : | |||
keyUsage | MUST | Y | See Section |
| : : : : 7.1.2.8.7 : | |||
basicConstraints | MAY | Y | See Section |
| : : : : 7.1.2.8.4 : | |||
nameConstraints | MUST NOT | - | - |
subjectAltName | MUST NOT | - | - |
subjectKeyIdentifier | SHOULD | N | See Section |
| : : : : 7.1.2.11.4 : | |||
authorityInformationAccess | NOT | N | See Section |
| : : RECOMMENDED : : 7.1.2.8.3 : | |||
certificatePolicies | MUST NOT | N | See Section |
| : : : : 7.1.2.8.8 : | |||
crlDistributionPoints | MUST NOT | N | See Section |
| : : : : 7.1.2.11.2 : | |||
| Signed Certificate Timestamp | MAY | N | See Section |
| : List : : : 7.1.2.11.3 : | |||
| Any other extension | NOT | - | See Section |
| : : RECOMMENDED : : 7.1.2.11.5 : |
For OCSP Responder certificates, this extension is NOT RECOMMENDED, as the Relying Party should already possess the necessary information. In order to validate the given Responder certificate, the Relying Party must have access to the Issuing CA’s certificate, eliminating the need to provide id-ad-caIssuers. Similarly, because of the requirement for an OCSP Responder certificate to include the id-pkix-ocspnocheck extension, it is not necessary to provide id-ad-ocsp, as such responses will not be checked by Relying Parties.
If present, the AuthorityInformationAccesssSyntax MUST contain one or more AccessDescriptions. Each AccessDescription MUST only contain a permitted accessMethod, as detailed below, and each AuthorityInfoAccessSyntax MUST contain all required AccessDescriptions.
| | | | | |
:---------------: | :----------------: | :-------------------------: | :-------------: | :---------: | :-:
Access Method | OID | Access Location | Presence | Maximum | Description
id-ad-ocsp | 1.3.6.1.5.5.7.48.1 | uniformResourceIdentifier | NOT RECOMMENDED | * | A HTTP URL of the Issuing CA's OCSP responder.
Any other value | - | - | MUST NOT | - | No other accessMethods may be used.
OCSP Responder certificates MUST NOT be CA certificates. The issuing CA may indicate this one of two ways: by omission of the basicConstraints extension, or through the inclusion of a basicConstraints extension that sets the cA boolean to FALSE.
| |
:-----------------: | :-----------------:
Field | Description
cA | MUST be FALSE
pathLenConstraint | MUST NOT be present
Note: Due to DER encoding rules regarding the encoding of DEFAULT values within OPTIONAL fields, a basicConstraints extension that sets the cA boolean to FALSE MUST have an extnValue OCTET STRING which is exactly the hex-encoded bytes 3000, the encoded representation of an empty ASN.1 SEQUENCE value.
| | |
:-----------------: | :---------------: | :----------:
Key Purpose | OID | Presence
id-kp-OCSPSigning | 1.3.6.1.5.5.7.3.9 | MUST
Any other value | - | MUST NOT
7.1.2.8.6 OCSP Responder id-pkix-ocsp-nocheck
The CA MUST include the id-pkix-ocsp-nocheck extension (OID: 1.3.6.1.5.5.7.48.1.5).
This extension MUST have an extnValue OCTET STRING which is exactly the hexencoded bytes 0500, the encoded representation of the ASN.1 NULL value, as specified in RFC 6960, Section 4.2.2.2.1.
7.1.2.8.7 OCSP Responder Key Usage
| | |
:----------------: | :-----------: | :----------:
Key Usage | Permitted | Required
digitalSignature | Y | Y
nonRepudiation | N | --
keyEncipherment | N | --
dataEncipherment | N | --
keyAgreement | N | --
keyCertSign | N | --
cRLSign | N | --
encipherOnly | N | --
decipherOnly | N | --
If present, the Certificate Policies extension MUST contain at least one PolicyInformation. Each PolicyInformation MUST match the following profile:
Permitted policyQualifiers
| Field | Presence | Contents |
| policyIdentifier | MUST | One of the following policy |
| : : : identifiers: : | ||
| A Reserved Certificate | NOT RECOMMENDED | |
| : Policy Identifier : : : | ||
| anyPolicy | NOT RECOMMENDED | |
| Any other identifier | NOT RECOMMENDED | If present, MUST be defined |
| : : : by the CA and documented by : | ||
| : : : the CA in its Certificate : | ||
| : : : Policy and/or Certification : | ||
| : : : Practice Statement. : | ||
| policyQualifiers | NOT RECOMMENDED | If present, MUST contain only |
| : : : permitted policyQualifiers : | ||
| : : : from the table below. : |
| Qualifier ID | Presence | Field Type | Contents |
id-qt-cps (OID: | MAY | IA5String | The HTTP or HTTPS URL |
| : 1.3.6.1.5.5.7.2.1) : : : for the Issuing CA's : | |||
| : : : : Certificate Policies, : | |||
| : : : : Certification Practice : | |||
| : : : : Statement, Relying : | |||
| : : : : Party Agreement, or : | |||
| : : : : other pointer to online : | |||
| : : : : policy information : | |||
| : : : : provided by the Issuing : | |||
| : : : : CA. : | |||
| Any other | MUST NOT | - | - |
| : qualifier : : : : |
Note: See Section 7.1.2.8.2 for applicable effective dates for when this extension may be included.
Note: Because the Certificate Policies extension may be used to restrict the applicable usages for a Certificate, incorrect policies may result in OCSP Responder Certificates that fail to successfully validate, resulting in invalid OCSP Responses. Including the anyPolicy policy can reduce this risk, but add to client processing complexity and interoperability issues.
A Precertificate is a signed data structure that can be submitted to a Certificate Transparency log, as defined by RFC 6962. A Precertificate appears structurally identical to a Certificate, with the exception of a special critical poison extension in the extensions field, with the OID of 1.3.6.1.4.1.11129.2.4.3. This extension ensures that the Precertificate will not be accepted as a Certificate by clients conforming to RFC 5280. The existence of a signed Precertificate can be treated as evidence of a corresponding Certificate also existing, as the signature represents a binding commitment by the CA that it may issue such a Certificate.
A Precertificate is created after a CA has decided to issue a Certificate, but prior to the actual signing of the Certificate. The CA MAY construct and sign a Precertificate corresponding to the Certificate, for purposes of submitting to Certificate Transparency Logs. The CA MAY use the returned Signed Certificate Timestamps to then alter the Certificate’s extensions field, adding a Signed Certificate Timestamp List, as defined in Section 7.1.2.11.3 and as permitted by the relevant profile, prior to signing the Certificate.
Once a Precertificate is signed, relying parties are permitted to treat this as a binding commitment from the CA of the intent to issue a corresponding Certificate, or more commonly, that a corresponding Certificate exists. A Certificate is said to be corresponding to a Precertificate based upon the value of the tbsCertificate contents, as transformed by the process defined in RFC 6962, Section 3.2.
This profile describes the transformations that are permitted to a Certificate to construct a Precertificate. CAs MUST NOT issue a Precertificate unless they are willing to issue a corresponding Certificate, regardless of whether they have done so. Similarly, a CA MUST NOT issue a Precertificate unless the corresponding Certificate conforms to these Baseline Requirements, regardless of whether the CA signs the corresponding Certificate.
A Precertificate may be issued either directly by the Issuing CA or by a Technically Constrained Precertificate Signing CA, as defined in Section 7.1.2.4 If issued by a Precertificate Signing CA, then in addition to the precertificate poison and signed certificate timestamp list extensions, the Precertificate issuer field and, if present, authorityKeyIdentifier extension, may differ from the Certificate, as described below.
Table 59: When the Precertificate is issued directly by the Issuing CA
| Field | Description |
tbsCertificate | |
version | Encoded value MUST be byte-for-byte identical |
: : to the version field of the Certificate : | |
serialNumber | Encoded value MUST be byte-for-byte identical |
: : to the serialNumber field of the Certificate : | |
signature | Encoded value MUST be byte-for-byte identical |
: : to the signature field of the Certificate : | |
issuer | Encoded value MUST be byte-for-byte identical |
: : to the issuer field of the Certificate : | |
validity | Encoded value MUST be byte-for-byte identical |
: : to the validity field of the Certificate : | |
subject | Encoded value MUST be byte-for-byte identical |
: : to the subject field of the Certificate : | |
subjectPublicKeyInfo | Encoded value MUST be byte-for-byte identical |
: : to the subjectPublicKeyInfo field of the : | |
| : : Certificate : | |
issuerUniqueID | Encoded value MUST be byte-for-byte identical |
: : to the issuerUniqueID field of the : | |
| : : Certificate, or omitted if omitted in the : | |
| : : Certificate : | |
subjectUniqueID | Encoded value MUST be byte-for-byte identical |
: : to the subjectUniqueID field of the : | |
| : : Certificate, or omitted if omitted in the : | |
| : : Certificate : | |
extensions | See Section 7.1.2.9.1 |
signatureAlgorithm | Encoded value MUST be byte-for-byte identical |
: : to the tbsCertificate.signature. : | |
signature |
Table 60: When the Precertificate is issued by a Precertificate Signing CA on behalf of an Issuing CA
| Field | Description |
tbsCertificate | |
version | Encoded value MUST be byte-for-byte identical |
: : to the version field of the Certificate : | |
serialNumber | Encoded value MUST be byte-for-byte identical |
: : to the serialNumber field of the Certificate : | |
signature | Encoded value MUST be byte-for-byte identical |
: : to the signature field of the Certificate : | |
issuer | Encoded value MUST be byte-for-byte identical |
: : to the subject field of the Precertificate : | |
| : : Signing CA Certificate : | |
validity | Encoded value MUST be byte-for-byte identical |
: : to the validity field of the Certificate : | |
subject | Encoded value MUST be byte-for-byte identical |
: : to the subject field of the Certificate : | |
subjectPublicKeyInfo | Encoded value MUST be byte-for-byte identical |
: : to the subjectPublicKeyInfo field of the : | |
| : : Certificate : | |
issuerUniqueID | Encoded value MUST be byte-for-byte identical |
: : to the issuerUniqueID field of the : | |
| : : Certificate, or omitted if omitted in the : | |
| : : Certificate : | |
subjectUniqueID | Encoded value MUST be byte-for-byte identical |
: : to the subjectUniqueID field of the : | |
| : : Certificate, or omitted if omitted in the : | |
| : : Certificate : | |
extensions | See Section 7.1.2.9.2 |
signatureAlgorithm | Encoded value MUST be byte-for-byte identical |
: : to the tbsCertificate.signature. : | |
signature |
Precertificate be identical to that of the corresponding Certificate. RFC 5280, Section 4.1.2.2 requires that the serialNumber of certificates be unique. For the purposes of this document, a Precertificate shall not be considered a “certificate” subject to that requirement, and thus may have the same serialNumber of the corresponding Certificate. However, this does not permit two Precertificates to share the same serialNumber, unless they correspond to the same Certificate, as this would otherwise indicate there are two corresponding Certificates that share the same serialNumber.
These extensions apply in the context of a Precertificate directly issued from a CA, and not from a Precertificate Signing CA Certificate, as defined in Section 7.1.2.4.
| Extension | Presence | Critical | Description |
| Precertificate Poison | MUST | Y | See Section |
| : (OID: : : : 7.1.2.9.3 : | |||
| : 1.3.6.1.4.1.11129.2.4.3) : : : : | |||
| Signed Certificate | MUST NOT | - | |
| : Timestamp List : : : : | |||
| Any other extension | * | * | The order, |
| : : : : criticality, : | |||
| : : : : and encoded : | |||
| : : : : values of all : | |||
| : : : : other : | |||
| : : : : extensions MUST : | |||
| : : : : be : | |||
| : : : : byte-for-byte : | |||
| : : : : identical to : | |||
| : : : : the : | |||
: : : : extensions : | |||
| : : : : field of the : | |||
| : : : : Certificate : |
Note: This requirement is expressing that if the Precertificate Poison extension is removed from the Precertificate, and the Signed Certificate Timestamp List is removed from the certificate, the contents of the extensions field MUST be byte-for-byte identical to the Certificate.
These extensions apply in the context of a Precertificate from a Precertificate Signing CA Certificate, as defined in Section 7.1.2.4. For such Precertificates, the authorityKeyIdentifier, if present in the Certificate, is modified in the Precertificate, as described in RFC 6962, Section 3.2.
| Extension | Presence | Critical | Description |
| Precertificate Poison | MUST | Y | See Section |
| : (OID: : : : 7.1.2.9.3 : | |||
| : 1.3.6.1.4.1.11129.2.4.3) : : : : | |||
authorityKeyIdentifier | * | * | See Section |
| : : : : 7.1.2.9.4 : | |||
| Signed Certificate | MUST NOT | - | |
| : Timestamp List : : : : | |||
| Any other extension | * | * | The order, |
| : : : : criticality, : | |||
| : : : : and encoded : | |||
| : : : : values of all : | |||
| : : : : other : | |||
| : : : : extensions MUST : | |||
| : : : : be : | |||
| : : : : byte-for-byte : | |||
| : : : : identical to : | |||
| : : : : the : | |||
: : : : extensions : | |||
| : : : : field of the : |
7.1.2.9.3 Precertificate Poison
The Precertificate MUST contain the Precertificate Poison extension (OID: 1.3.6.1.4.1.11129.2.4.3).
This extension MUST have an extnValue OCTET STRING which is exactly the hex-encoded bytes 0500, the encoded representation of the ASN.1 NULL value, as specified in RFC 6962, Section 3.1.
For Precertificates issued by a Precertificate Signing CA, the contents of the authorityKeyIdentifier extension MUST be one of the following:
SHOULD be as defined in the profile below, or;
MAY be byte‐for‐byte identical with the contents of the authorityKeyIdentifier extension of the corresponding Certificate.
| Field | Description |
keyIdentifier | MUST be present. MUST be identical to the |
: : subjectKeyIdentifier field of the : | |
| : : Precertificate Signing CA Certificate : | |
authorityCertIssuer | MUST NOT be present |
authorityCertSerialNumber | MUST NOT be present |
This section contains several fields that are common among multiple CA Certificate profiles. However, these fields may not be common among all CA Certificate profiles. Before issuing a certificate, the CA MUST ensure the certificate contents, including the contents of each field, complies in whole with all of the requirements of at least one Certificate Profile documented in Section 7.1.2.
| | |
:---------: | :----------------------------------: | :-----------------:
Field | Minimum | Maximum
notBefore | One day prior to the time of signing | The time of signing
notAfter | The time of signing | Unspecified
All subject names MUST be encoded as specified in Section 7.1.4
The following table details the acceptable AttributeTypes that may appear within the type field of an AttributeTypeAndValue, as well as the contents permitted within the value field.
:----------------: | :----------:
| :---------------------------------------------------------- : | Attribute
Name | Presence | Value | countryName | MUST | US |
organizationName | MUST | Google Trust Services or Google Trust Services LLC | commonName | MUST | Unique certificate identifier across all
certificates issued by the issuing certificate. |
If present, the AuthorityInfoAccessSyntax MUST contain one or more AccessDescriptions. Each AccessDescription MUST only contain a permitted accessMethod, as detailed below, and each accessLocation MUST be encoded as the specified GeneralName type.
The AuthorityInfoAccessSyntax MAY contain multiple AccessDescriptions with the same accessMethod, if permitted for that accessMethod. When multiple AccessDescriptions are present with the same accessMethod, each accessLocation MUST be unique, and each AccessDescription MUST be ordered in priority for that accessMethod, with the most‐preferred accessLocation being the first AccessDescription. No ordering requirements are given for AccessDescriptions that contain different accessMethods, provided that previous requirement is satisfied.
| | | | | |
:---------------: | :----------------: | :-------------------------: | :----------: | :---------: | :-:
Access Method | OID | Access Location | Presence | Maximum | Description
id-ad-ocsp | 1.3.6.1.5.5.7.48.1 | uniformResourceIdentifier | SHOULD | * | A HTTP URL of the Issuing CA's OCSP responder.
id-ad-caIssuers | 1.3.6.1.5.5.7.48.2 | uniformResourceIdentifier | MAY | * | A HTTP URL of the Issuing CA's certificate.
Any other value | - | - | MUST NOT | - | No other accessMethods may be used.
| |
:-----------------: | :--------------:
Field | Description
cA | MUST be set TRUE
pathLenConstraint | MAY be present
***7.1.2.10.5 CA Certificate Certificate Policies
If present, the Certificate Policies extension MUST contain at least one PolicyInformation. Each PolicyInformation MUST match the following profile:
Table 68: No Policy Restrictions (Affiliated CA)
| Field | Presence | Contents |
policyIdentifier | MUST | When the Issuing CA wishes to express |
| : : : that there are no policy : | ||
| : : : restrictions, the Subordinate CA MUST : | ||
| : : : be an Affiliate of the Issuing CA. : | ||
| : : : The Certificate Policies extension : | ||
| : : : MUST contain only a single : | ||
: : : PolicyInformation value, which MUST : | ||
: : : contain the anyPolicy Policy : | ||
| : : : Identifier. : | ||
anyPolicy | MUST | |
policyQualifiers | NOT RECOMMENDED | If present, MUST contain only |
: : : permitted policyQualifiers from the : | ||
| : : : table below. : |
Table 69: Policy Restricted
| Field | Presence | Contents |
policyIdentifier | MUST | One of the following policy |
| : : : identifiers: : | ||
| A Reserved Certificate | MUST | The CA MUST include at least |
| : Policy Identifier : : one Reserved Certificate : | ||
| : : : Policy Identifier (see : | ||
| : : : Section 7.1.6.1) associated : | ||
| : : : with the given Subscriber : | ||
| : : : Certificate type (see Section : | ||
| : : : 7.1.2.7.1]) directly or : | ||
| : : : transitively issued by this : | ||
| : : : Certificate. : | ||
anyPolicy | MUST NOT | The anyPolicy Policy |
| : : : Identifier MUST NOT be : | ||
| : : : present. : | ||
| Any other identifier | MAY | If present, MUST be defined |
| : : : by the CA and documented by : | ||
| : : : the CA in its Certificate : | ||
| : : : Policy and/or Certification : | ||
| : : : Practice Statement. : | ||
policyQualifiers | NOT RECOMMENDED | If present, MUST contain only |
: : : permitted policyQualifiers : | ||
| : : : from the table below. : |
This Profile RECOMMENDS that the first PolicyInformation value within the Certificate Policies extension contains the Reserved Certificate Policy Identifier (see 7.1.6.1) Regardless of the order of PolicyInformation values, the Certificate Policies extension MUST contain exactly one Reserved Certificate Policy Identifier.
If the policyQualifiers is permitted and present within a PolicyInformation field, it MUST be formatted as follows:
Permitted policyQualifiers
| Qualifier ID | Presence | Field Type | Contents |
id-qt-cps (OID: | MAY | IA5String | The HTTP or HTTPS URL |
| : 1.3.6.1.5.5.7.2.1) : : : for the Issuing CA's : | |||
| : : : : Certificate Policies, : | |||
| : : : : Certification Practice : | |||
| : : : : Statement, Relying : | |||
| : : : : Party Agreement, or : | |||
| : : : : other pointer to online : | |||
| : : : : policy information : | |||
| : : : : provided by the Issuing : | |||
| : : : : CA. : | |||
| Any other | MUST NOT | - | - |
| : qualifier : : : : |
| | |
:--------------------------------: | :---------------------: | :-------------:
Key Purpose | OID | Presence
id-kp-serverAuth | 1.3.6.1.5.5.7.3.1 | MUST
id-kp-clientAuth | 1.3.6.1.5.5.7.3.2 | MAY
id-kp-codeSigning | 1.3.6.1.5.5.7.3.3 | MUST NOT
id-kp-emailProtection | 1.3.6.1.5.5.7.3.4 | MUST NOT
id-kp-timeStamping | 1.3.6.1.5.5.7.3.8 | MUST NOT
id-kp-OCSPSigning | 1.3.6.1.5.5.7.3.9 | MUST NOT
anyExtendedKeyUsage | 2.5.29.37.0 | MUST NOT
Precertificate Signing Certificate | 1.3.6.1.4.1.11129.2.4.4 | MUST NOT
Any other value | - | NOT RECOMMENDED
7.1.2.10.7 CA Certificate Key Usage Key Usage
| | |
:----------------: | :-----------: | :----------:
Key Usage | Permitted | Required
digitalSignature | Y | N
nonRepudiation | N | --
keyEncipherment | N | --
dataEncipherment | N | --
keyAgreement | N | --
keyCertSign | Y | Y
cRLSign | Y | Y
encipherOnly | N | --
decipherOnly | N | --
If present, the Name Constraints extension MUST be encoded as follows. As an explicit exception from RFC 5280, this extension SHOULD be marked critical, but MAY be marked non‐critical if compatibility with certain legacy applications that do not support Name Constraints is necessary.
Table 73: nameConstraints requirements
| Field | Description |
permittedSubtrees | |
GeneralSubtree | The requirements for a GeneralSubtree that appears |
: : within a permittedSubtrees. : | |
base | See following table. |
minimum | MUST NOT be present. |
maximum | MUST NOT be present. |
excludedSubtrees | |
GeneralSubtree | The requirements for a GeneralSubtree that appears |
: : within a permittedSubtrees. : | |
base | See following table. |
minimum | MUST NOT be present. |
maximum | MUST NOT be present. |
The following table contains the requirements for the GeneralName that appears within the base of a GeneralSubtree in either the permittedSubtrees or excludedSubtrees.
| Name Type | Presence | **Permitted | **Excluded |
| : : : Subtrees** : Subtrees** : | |||
dNSName | MAY | The CA MUST | If at least one |
: : : confirm that the : dNSName instance : | |||
| : : : Applicant has : is present in the : | |||
: : : registered the : permittedSubtrees, : | |||
: : : dNSName or has : the CA MAY indicate : | |||
| : : : been authorized : one or more : | |||
| : : : by the domain : subordinate domains : | |||
| : : : registrant to act : to be excluded. : | |||
| : : : on the : : | |||
| : : : registrant's : : | |||
| : : : behalf. See : : | |||
| : : : Section 3.2.2 4. : : | |||
iPAddress | MAY | The CA MUST | If at least one |
: : : confirm that the : iPAddress instance : | |||
| : : : Applicant has : is present in the : | |||
: : : been assigned the : permittedSubtrees, : | |||
: : : iPAddress range : the CA MAY indicate : | |||
| : : : or has been : one or more : | |||
| : : : authorized by the : subdivisions of : | |||
| : : : assigner to act : those ranges to be : | |||
| : : : on the asignee's : excluded. : | |||
| : : : behalf. See : : | |||
| : : : Section 3.2.2.5 : : | |||
directoryName | MAY | The CA MUST | It is NOT |
| : : : confirm the : RECOMMENDED to : | |||
| : : : Applicant's : include values : | |||
| : : : and/or : within : | |||
: : : Subsidiary's name : excludedSubtrees. : | |||
| : : : attributes such : : | |||
| : : : that all : : | |||
| : : : certificates : : | |||
| : : : issued will : : | |||
| : : : comply with the : : | |||
| : : : relevant : : | |||
| : : : Certificate : : | |||
| : : : Profile (see : : | |||
| : : : Section 7.1.2), : : | |||
| : : : including Name : : | |||
| : : : Forms (See : : | |||
| : : : Section 7.1.4). : : | |||
rfc822Name | NOT RECOMMENDED | The CA MAY | If at least one |
: : : constrain to a : rfc822Name : | |||
| : : : mailbox, a : instance is present : | |||
| : : : particular host, : in the : | |||
: : : or any address : permittedSubtrees, : | |||
| : : : within a domain, : the CA MAY indicate : | |||
| : : : as specified : one or more : | |||
| : : : within RFC 5280, : mailboxes, hosts, or : | |||
| : : : Section 4.2.1.10. : domains to be : | |||
| : : : For each host, : excluded. : | |||
| : : : domain, or Domain : : | |||
| : : : portion of a : : | |||
| : : : Mailbox (as : : | |||
| : : : specified within : : | |||
| : : : RFC 5280, Section : : | |||
| : : : 4.2.1.6), the CA : : | |||
| : : : MUST confirm that : : | |||
| : : : the Applicant has : : | |||
| : : : registered the : : | |||
| : : : domain or has : : | |||
| : : : been authorized : : | |||
| : : : by the domain : : | |||
| : : : registrant to act : : | |||
| : : : on the : : | |||
| : : : registrant's : : | |||
| : : : behalf. See : : | |||
| : : : Section 3.2.2.4. : : | |||
otherName | NOT RECOMMENDED | See below | See below |
| Any other value | NOT RECOMMENDED | - | - |
Any otherName, if present:
MUST apply in the context of the public Internet, unless:
MUST NOT include semantics that will mislead the Relying Party about certificate information verified by the CA.
MUST be DER encoded according to the relevant ASN.1 module defining the otherName type-id and value.
CAs SHALL NOT include additional names unless the CA is aware of a reason for including the data in the Certificate.
This section contains several fields that are common among multiple certificate profiles. However, these fields may not be common among all certificate profiles. Before issuing a certificate, the CA MUST ensure the certificate contents, including the contents of each field, complies in whole with all of the requirements of at least one Certificate Profile documented in Section 7.1.2.
| Field | Description |
keyIdentifier | MUST be present. MUST be identical to the |
: : subjectKeyIdentifier field of the Issuing : | |
| : : CA. : | |
authorityCertIssuer | MUST NOT be present |
authorityCertSerialNumber | MUST NOT be present |
If present, the CRL Distribution Points extension MUST contain at least one DistributionPoint; containing more than one is NOT RECOMMENDED. All DistributionPoint items must be formatted as follows:
Table: DistributionPoint profile
| Field | Presence | Description |
distributionPoint | MUST | The DistributionPointName MUST be a |
: : : fullName formatted as described : | ||
| : : : below. : | ||
reasons | MUST NOT | |
cRLIssuer | MUST NOT |
A fullName MUST contain at least one GeneralName; it MAY contain more than one. All GeneralNames MUST be of type uniformResourceIdentifier, and the scheme of each MUST be “http”. The first GeneralName must contain the HTTP URL of the Issuing CA’s CRL service for this certificate.
If present, the Signed Certificate Timestamp List extension contents MUST be an OCTET STRING containing the encoded SignedCertificateTimestampList, as specified in RFC 6962, Section 3.3.
Each SignedCertificateTimestamp included within the SignedCertificateTimestampList MUST be for a PreCert LogEntryType that corresponds to the current certificate.
If present, the subjectKeyIdentifier MUST be set as defined within RFC 5280, Section 4.2.1.2. The CA MUST generate a subjectKeyIdentifier that is unique within the scope of all Certificates it has issued for each unique public key (the subjectPublicKeyInfo field of the tbsCertificate). For example, CAs may generate the subject key identifier using an algorithm derived from the public key, or may generate a sufficiently-large unique number, such by using a CSPRNG.
All extensions and extension values not directly addressed by the applicable certificate profile:
MUST apply in the context of the public Internet, unless: a. the extension OID falls within an OID arc for which the Applicant demonstrates ownership, or, b. the Applicant can otherwise demonstrate the right to assert the data in a public context.
MUST NOT include semantics that will mislead the Relying Party about certificate information verified by the CA (such as including an extension that indicates a Private Key is stored on a smart card, where the CA is not able to verify that the corresponding Private Key is confined to such hardware due to remote issuance).
MUST be DER encoded according to the relevant ASN.1 module defining the extension and extension values.
CAs SHALL NOT include additional extensions or values unless the CA is aware of a reason for including the data in the Certificate.
The following requirements apply to the subjectPublicKeyInfo field within a Certificate or Precertificate. No other encodings are permitted.
The CA SHALL indicate an RSA key using the rsaEncryption (OID: 1.2.840.113549.1.1.1) algorithm identifier. The parameters MUST be present, and MUST be an explicit NULL. The CA SHALL NOT use a different algorithm, such as the id-RSASSA-PSS (OID: 1.2.840.113549.1.1.10) algorithm identifier, to indicate an RSA key.
When encoded, the AlgorithmIdentifier for RSA keys MUST be byte-for-byte identical with the following hex-encoded bytes: 30 0d 06 09 2a 86 48 86 f7 0d 01 01 01 05 00
The CA SHALL indicate an ECDSA key using the id-ecPublicKey (OID: 1.2.840.10045.2.1) algorithm identifier. The parameters MUST use the namedCurve encoding.
When encoded, the AlgorithmIdentifier for ECDSA keys MUST be byte-for-byte identical with the following hex-encoded bytes:
All objects signed by a CA Private Key MUST conform to these requirements on the use of the AlgorithmIdentifier or AlgorithmIdentifier-derived type in the context of signatures.
In particular, it applies to all of the following objects and fields:
No other encodings are permitted for these fields.
The CA SHALL use one of the following signature algorithms and encodings. When encoded, the AlgorithmIdentifier MUST be byte-for-byte identical with the specified hex-encoded bytes.
In addition, the CA MAY use the following signature algorithm and encoding if all of the following conditions are met:
If used within a Certificate, such as the signatureAlgorithm field of a Certificate or the signature field of a TBSCertificate:
The new Certificate is a Root CA Certificate or Subordinate CA Certificate that is a Cross-Certificate; and,
There is an existing Certificate, issued by the same issuing CA Certificate, using the following encoding for the signature algorithm; and,
The existing Certificate has a serialNumber that is at least 64-bits long; and,
The only differences between the new Certificate and existing Certificate are one of the following:
If used within an OCSP response, such as the signatureAlgorithm of a BasicOCSPResponse:
If used within a CRL, such as the signatureAlgorithm field of a CertificateList or the signature field of a TBSCertList:
Note: The above requirements do not permit a CA to sign a Precertificate with this encoding.
The CA SHALL use the appropriate signature algorithm and encoding based upon the signing key used.
If the signing key is P-256, the signature MUST use ECDSA with SHA-256. When encoded, the AlgorithmIdentifier MUST be byte-for-byte identical with the following hex-encoded bytes: 300a06082a8648ce3d040302.
If the signing key is P-384, the signature MUST use ECDSA with SHA-384. When encoded, the AlgorithmIdentifier MUST be byte-for-byte identical with the following hex-encoded bytes: 300a06082a8648ce3d040303.
If the signing key is P-521, the signature MUST use ECDSA with SHA-512. When encoded, the AlgorithmIdentifier MUST be byte-for-byte identical with the following hex-encoded bytes: 300a06082a8648ce3d040304.
This section details encoding rules that apply to all Certificates issued by a CA. Further restrictions may be specified within Section 7.1.2, but these restrictions do not supersede these requirements.
The following requirements apply to all Certificates listed in Section 7.1.2. Specifically, this includes Technically Constrained Non-TLS Subordinate CA Certificates, as defined in Section 7.1.2.3, but does not include certificates issued by such CA Certificates, as they are out of scope of these Baseline Requirements.
For every valid Certification Path (as defined by RFC 5280, Section 6):
When encoding a Name, the CA SHALL ensure that:
Each Name MUST contain an RDNSequence.
Each RelativeDistinguishedName MUST contain exactly one AttributeTypeAndValue.
Each RelativeDistinguishedName, if present, is encoded within the RDNSequence in the order that it appears in Section 7.1.4.2.
Each Name MUST NOT contain more than one instance of a given AttributeTypeAndValue across all RelativeDistinguishedNames unless explicitly allowed in these Requirements.
This document defines requirements for the content and validation of a number of attributes that may appear within the subject field of a tbsCertificate. CAs SHALL NOT include these attributes unless their content has been validated as specified by, and only if permitted by, the relevant certificate profile specified within Section 7.1.2.
CAs that include attributes in the Certificate subject field that are listed in the table below SHALL encode those attributes in the relative order as they appear in the table and follow the specified encoding requirements for the attribute.
Encoding and Order Requirements for Selected Attributes
| | | | |
:----------------------: | :--------------------------: | :---------------: | :----------------------------------------: | :-:
Attribute | OID | Specification | Encoding Requirements | Max Length
domainComponent | 0.9.2342.19200300.100.1.25 | RFC 4519 | MUST use IA5String | 63
countryName | 2.5.4.6 | RFC 5280 | MUST use PrintableString | 2
stateOrProvinceName | 2.5.4.8 | RFC 5280 | MUST use UTF8String or PrintableString | 128
localityName | 2.5.4.7 | RFC 5280 | MUST use UTF8String or PrintableString | 128
postalCode | 2.5.4.17 | X.520 | MUST use UTF8String or PrintableString | 40
streetAddress | 2.5.4.9 | X.520 | MUST use UTF8String or PrintableString | 128
organizationName | 2.5.4.10 | RFC 5280 | MUST use UTF8String or PrintableString | 64
surname | 2.5.4.4 | RFC 5280 | MUST use UTF8String or PrintableString | 64
givenName | 2.5.4.42 | RFC 5280 | MUST use UTF8String or PrintableString | 64
organizationalUnitName | 2.5.4.11 | RFC 5280 | MUST use UTF8String or PrintableString | 64
commonName | 2.5.4.3 | RFC 5280 | MUST use UTF8String or PrintableString | 64
CAs that include attributes in the Certificate subject field that are listed in the table below SHALL follow the specified encoding requirements for the attribute.
Encoding Requirements for Selected Attributes
| | | | |
:---------------------------: | :------------------------: | :----------------------------------------------------------------------------: | :----------------------------------------: | :-:
Attribute | OID | Specification | Encoding Requirements | Max Length
businessCategory | 2.5.4.15 | X.520 | MUST use UTF8String or PrintableString | 128
jurisdictionCountry | 1.3.6.1.4.1.311.60.2.1.3 | Guidelines for the Issuance and Management of Extended Validation Certificates | MUST use PrintableString | 2
jurisdictionStateOrProvince | 1.3.6.1.4.1.311.60.2.1.2 | Guidelines for the Issuance and Management of Extended Validation Certificates | MUST use UTF8String or PrintableString | 128
jurisdictionLocality | 1.3.6.1.4.1.311.60.2.1.1 | Guidelines for the Issuance and Management of Extended Validation Certificates | MUST use UTF8String or PrintableString | 128
serialNumber | 2.5.4.5 | RFC 5280 | MUST use PrintableString | 64
organizationIdentifier | 2.5.4.97 | X.520 | MUST use UTF8String or PrintableString | None
By issuing a Subordinate CA Certificate, the CA represents that it followed the procedure set forth in its Certificate Policy and/or Certification Practice Statement to verify that, as of the Certificate's issuance date, all of the Subject Information was accurate.
When explicitly stated as permitted by the relevant certificate profile specified within Section 7.1.2, CAs MAY include additional attributes within the AttributeTypeAndValue beyond those specified in Section 7.1.4.2
Before including such an attribute, the CA SHALL:
The following Certificate Policy identifiers are reserved for use by CAs as an optional means of asserting that a Certificate complies with these Requirements.
{joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-policies(1) baseline-requirements(2) domain-validated(1)} (2.23.140.1.2.1)
{joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-policies(1) baseline-requirements(2) organization-validated(2)} (2.23.140.1.2.2)
{joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-policies(1) baseline-requirements(2) individual-validated(3)} (2.23.140.1.2.3)
{joint‐iso‐itu‐t(2) international‐organizations(23) ca‐browser‐forum(140) certificate‐policies(1) ev-guidelines(1)} (2.23.140.1.1)
No stipulation.
No stipulation.
No stipulation.
No stipulation.
reasonCode (OID 2.5.29.21)
If present, this extension MUST NOT be marked critical.
If a CRL entry is for a Root CA or Subordinate CA Certificate, including Cross-Certified Subordinate CA Certificates, this CRL entry extension MUST be present. If a CRL entry is for a Certificate not technically capable of causing issuance, this CRL entry extension SHOULD be present, but MAY be omitted, subject to the following requirements.
The CRLReason indicated MUST NOT be unspecified (0). If the reason for
revocation is unspecified, CAs MUST omit reasonCode entry extension, if
allowed by the previous requirements. If a CRL entry is for aCertificate not
subject to these Requirements and was either issued on-or-after 2020-09-30
or has a notBefore on-or-after 2020-09-30, the CRLReason MUST NOT be
certificateHold (6). If a CRL entry is for a Certificate subject to these
Requirements, the CRLReason MUST NOT be certificateHold (6).
If a reasonCode CRL entry extension is present, the CRLReason MUST
indicate the most appropriate reason for revocation of the Certificate.
CRLReason MUST be included in the reasonCode extension of the CRL entry
corresponding to a Subscriber Certificate that is revoked after July 15,
2023, unless the CRLReason is "unspecified (0)". Revocation reason code
entries for Subscriber Certificates revoked prior to July 15, 2023, do NOT
need to be added or changed.
Only the following CRLReasons MAY be present in the CRL reasonCode
extension for Subscriber Certifificates:
The Subscriber Agreement, or an online resource referenced therein, MUST inform Subscribers about the revocation reason options listed above and provide explanation about when to choose each option. Tools that the CA provides to the Subscriber MUST 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).
The privilegeWithdrawn reasonCode SHOULD NOT be made available to the Subscriber as a revocation reason option, because the use of this reasonCode is determined by the CA and not the Subscriber.
When a CA 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, the CA SHOULD update the CRL entry to enter keyCompromise as the CRLReason in the reasonCode extension. Additionally, the CA SHOULD 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.
issuingDistributionPoint (OID 2.5.29.28)
Effective 2023-01-15, if a CRL does not contain entries for all revoked
unexpired certificates issued by the CRL issuer, then it MUST contain a
critical Issuing Distribution Point extension and MUST populate the
distributionPoint field of that extension.
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 MUST be present.
The CRLReason indicated MUST contain a value permitted for CRLs, as specified in Section 7.2.2.
No stipulation.
The singleExtensions of an OCSP response MUST NOT contain the reasonCode (OID 2.5.29.21) CRL entry extension
The CA SHALL at all times:
Certificates that are capable of being used to issue new certificates MUST either be Technically Constrained in line with section 7.1.2.3, Section 7.1.2.4, or Section 7.1.2.5 as well as audited in line with section 8.7 only, or Unconstrained and fully audited in line with all remaining requirements from this section. A Certificate is deemed as capable of being used to issue new certificates if it contains an X.509v3 basicConstraints extension, with the cA boolean set to true and is therefore by definition a Root CA Certificate or a Subordinate CA Certificate.
The period during which the CA issues Certificates SHALL be divided into an unbroken sequence of audit periods. An audit period MUST NOT exceed one year in duration.
If the CA has a currently valid Audit Report indicating compliance with an audit scheme listed in Section 8.4, then no pre-issuance readiness assessment is necessary.
If the CA does not have a currently valid Audit Report indicating compliance with one of the audit schemes listed in Section 8.4, then, before issuing Publicly-Trusted Certificates, the CA SHALL successfully complete a point-in-time readiness assessment performed in accordance with applicable standards under one of the audit schemes listed in Section 8.4. The point-in-time readiness assessment SHALL be completed no earlier than twelve (12) months prior to issuing Publicly-Trusted Certificates and SHALL be followed by a complete audit under such scheme within ninety (90) days of issuing the first Publicly-Trusted Certificate.
The CA's audit SHALL be performed by a Qualified Auditor. A Qualified Auditor means a natural person, Legal Entity, or group of natural persons or Legal Entities that collectively possess the following qualifications and skills:
Qualified Auditors must hold omissions insurance with policy limits of at least one million US dollars in coverage.
No stipulation.
The CA SHALL undergo an audit in accordance with one of the following schemes:
“WebTrust for CAs v2.1 or newer” AND “WebTrust for CAs SSL Baseline with Network Security v2.3 or newer”; or
ETSI EN 319 411-1 v1.2.2, which includes normative references to ETSI EN 319 401 (the latest version of the referenced ETSI documents should be applied); or
If a Government CA is required by its Certificate Policy to use a different internal audit scheme, it MAY use such scheme provided that the audit either (a) encompasses all requirements of one of the above schemes or (b) consists of comparable criteria that are available for public review.
Whichever scheme is chosen, it MUST incorporate periodic monitoring and/or accountability procedures to ensure that its audits continue to be conducted in accordance with the requirements of the scheme.
The audit MUST be conducted by a Qualified Auditor, as specified in Section 8.2.
For Delegated Third Parties which are not Enterprise RAs, then the CA SHALL obtain an audit report, issued under the auditing standards that underlie the accepted audit schemes found in Section 8.4, that provides an opinion whether the Delegated Third Party's performance complies with either the Delegated Third Party's practice statement or the CA's Certificate Policy and/or Certification Practice Statement. If the opinion is that the Delegated Third Party does not comply, then the CA SHALL not allow the Delegated Third Party to continue performing delegated functions.
The audit period for the Delegated Third Party SHALL NOT exceed one year (ideally aligned with the CA's audit). However, if the CA or Delegated Third Party is under the operation, control, or supervision of a Government Entity and the audit scheme is completed over multiple years, then the annual audit MUST cover at least the core controls that are required to be audited annually by such scheme plus that portion of all non-core controls that are allowed to be conducted less frequently, but in no case may any non-core control be audited less often than once every three years.
No stipulation.
The Audit Report SHALL state explicitly that it 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 CA SHALL make the Audit Report publicly available.
The CA MUST make its Audit Report publicly available no later than three months after the end of the audit period. In the event of a delay greater than three months, the CA SHALL provide an explanatory letter signed by the Qualified Auditor.
The Audit Report MUST contain at least the following clearly-labelled information:
An authoritative English language version of the publicly available audit information MUST be provided by the Qualified Auditor and the CA SHALL ensure it is publicly available.
The Audit Report MUST be available as a PDF, and SHALL be text searchable for all information required. Each SHA-256 fingerprint within the Audit Report MUST be uppercase letters and MUST NOT contain colons, spaces, or line feeds.
During the period in which the CA issues Certificates, the CA SHALL monitor adherence to its Certificate Policy, Certification Practice Statement and these Requirements and strictly control its service quality by performing self audits on at least a quarterly basis against a randomly selected sample of the greater of one certificate or at least three percent of the Certificates issued by it during the period commencing immediately after the previous self-audit sample was taken. Except for Delegated Third Parties that undergo an annual audit that meets the criteria specified in Section 8.4, the CA SHALL strictly control the service quality of Certificates issued or containing information verified by a Delegated Third Party by having a Validation Specialist employed by the CA perform ongoing quarterly audits against a randomly selected sample of at least the greater of one certificate or three percent of the Certificates verified by the Delegated Third Party in the period beginning immediately after the last sample was taken. The CA SHALL review each Delegated Third Party's practices and procedures to ensure that the Delegated Third Party is in compliance with these Requirements and the relevant Certificate Policy and/or Certification Practice Statement.
The CA SHALL internally audit each Delegated Third Party's compliance with these Requirements on an annual basis.
During the period in which a Technically Constrained Subordinate CA issues Certificates, the CA which signed the Subordinate CA SHALL monitor adherence to the CA's Certificate Policy and the Subordinate CA's Certification Practice Statement. On at least a quarterly basis, against a randomly selected sample of the greater of one certificate or at least three percent of the Certificates issued by the Subordinate CA, during the period commencing immediately after the previous audit sample was taken, the CA SHALL ensure all applicable CP are met.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
By issuing a Certificate, the CA makes the certificate warranties listed herein to the following Certificate Beneficiaries:
The CA represents and warrants to the Certificate Beneficiaries that, during the period when the Certificate is valid, the CA has complied with these Requirements and its Certificate Policy and/or Certification Practice Statement in issuing and managing the Certificate.
The Certificate Warranties specifically include, but are not limited to, the following:
No stipulation.
The CA SHALL require, as part of the Subscriber or Terms of Use Agreement, that the Applicant make the commitments and warranties in this section for the benefit of the CA and the Certificate Beneficiaries. Prior to the issuance of a Certificate, the CA SHALL obtain, for the express benefit of the CA and the Certificate Beneficiaries, either:
The CA SHALL implement a process to ensure that each Subscriber or Terms of Use Agreement is legally enforceable against the Applicant. In either case, the Agreement MUST apply to the Certificate to be issued pursuant to the certificate request. The CA may use an electronic or "click-through" Agreement provided that the CA has determined that such agreements are legally enforceable. A separate Agreement MAY be used for each certificate request, or a single Agreement MAY be used to cover multiple future certificate requests and the resulting Certificates, so long as each Certificate that the CA issues to the Applicant is clearly covered by that Subscriber or Terms of Use Agreement. The Subscriber or Terms of Use Agreement MUST contain provisions imposing on the Applicant itself (or made by the Applicant on behalf of its principal or agent under a subcontractor or hosting service relationship) the following obligations and warranties:
No stipulation.
No stipulation.
No stipulation.
For delegated tasks, the CA and any Delegated Third Party MAY allocate liability between themselves contractually as they determine, but the CA SHALL remain fully responsible for the performance of all parties in accordance with these Requirements, as if the tasks had not been delegated.
If the CA has issued and managed the Certificate in compliance with these Requirements and its Certificate Policy and/or Certification Practice Statement, the CA may disclaim liability to the Certificate Beneficiaries or any other third parties for any losses suffered as a result of use or reliance on such Certificate beyond those specified in the CA's Certification Practice Statement. If the CA has not issued or managed the Certificate in compliance with applicable requirements and its Certification Practice Statement, the CA may seek to limit its liability to the Subscriber and to Relying Parties, regardless of the cause of action or legal theory involved, for any and all claims, losses or damages suffered as a result of the use or reliance on such Certificate by any appropriate means that the CA desires. If the CA chooses to so limit its liability, then the CA SHALL include the limitations on liability in its Certification Practice Statement.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
The CA 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.
No stipulation.
No stipulation.
In the event of a conflict between this CP and a law, regulation or government order (hereinafter 'Law') of any jurisdiction in which a CA operates or issues certificates, a CA MAY modify any conflicting requirement to the minimum extent necessary to make the requirement valid and legal in the jurisdiction. This applies only to operations or certificate issuances that are subject to that Law. In such event, the CA SHALL immediately (and prior to issuing a certificate under the modified requirement) include in Section 9.16.3 of the CA's CPS a detailed reference to the Law requiring a modification of these Requirements under this section, and the specific modification to these Requirements implemented by the CA.
The CA MUST also (prior to issuing a certificate under the modified requirement) notify the CA/Browser Forum of the relevant information newly added to its CPS by sending a message to questions@cabforum.org and receiving confirmation that it has been posted to the Public Mailing List and is indexed in the Public Mail Archives available at https://cabforum.org/pipermail/public/ (or such other email addresses and links as the Forum may designate), so that the CA/Browser Forum may consider possible revisions to these Requirements accordingly.
Any modification to CA practice enabled under this section MUST be discontinued if and when the Law no longer applies, or these Requirements are modified to make it possible to comply with both them and the Law simultaneously. An appropriate change in practice, modification to the CPS and a notice to the CA/Browser Forum, as outlined above, MUST be made within 90 days.
No stipulation.
No stipulation.
No stipulation.
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.
Applicant Representative: A natural person or human sponsor who is either the Applicant, employed by the Applicant, or an authorized agent who has express authority to represent the Applicant: (i) who signs and submits, or approves a certificate request on behalf of the Applicant, and/or (ii) who signs and submits a Subscriber Agreement on behalf of the Applicant, and/or (iii) who acknowledges the Terms of Use on behalf of the Applicant when the Applicant is an Affiliate of the CA or is the CA.
Application Software Supplier: A supplier of Internet browser software or other relying-party application software that displays or uses Certificates and incorporates Root Certificates.
Attestation Letter: A letter attesting that Subject Information is correct written by an accountant, lawyer, government official, or other reliable third party customarily relied upon for such information.
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 auditors in their engagement. (This is not the same as the period of time when the auditors are on-site at the CA.) The coverage rules and maximum length of audit periods are defined in section 8.1.
Audit Report: A report from a Qualified Auditor stating the Qualified Auditor's opinion on whether an entity's processes and controls comply with the mandatory provisions of these Requirements.
Authorization Domain Name: The FQDN used to obtain authorization for a given
FQDN to be included in a Certificate. The CA 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 the CA MUST remove
"*." from the left-most portion of the Wildcard Domain Name to yield the
corresponding FQDN. The CA 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).
Base Domain Name: The portion of an applied-for FQDN that is the first Domain Name node left of a registry-controlled or public suffix plus the registry-controlled or public suffix (e.g. "example.co.uk" or "example.com"). For FQDNs where the right-most Domain Name node is a gTLD having ICANN Specification 13 in its registry agreement, the gTLD itself may be used as the Base Domain Name.
Baseline Requirements (BR): CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly Trusted 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).
Certificate: An electronic document that uses a digital signature to bind a public key and an identity.
Certificate Data: Certificate requests and data related thereto (whether obtained from the Applicant or otherwise) in the CA's possession or control or to which the CA has access.
Certificate Management Process: Processes, practices, and procedures associated with the use of keys, software, and hardware, by which the CA verifies Certificate Data, issues Certificates, maintains a Repository, and revokes Certificates.
Certificate Policy: A set of rules that indicates the applicability of a named Certificate to a particular community and/or PKI implementation with common security requirements.
Certificate Problem Report: Complaint of suspected Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, or inappropriate conduct related to Certificates.
Certificate Revocation List: A regularly updated time-stamped list of revoked Certificates that is created and digitally signed by the CA that issued the Certificates.
Certification Authority: An organization that is responsible for the creation, issuance, revocation, and management of Certificates. The term applies equally to both Root CAs and Subordinate CAs.
Certification Practice Statement: One of several documents forming the governance framework in which Certificates are created, issued, managed, and used.
Certificate Profile: A set of documents or files that defines requirements for Certificate content and Certificate extensions in accordance with Section 7 of the Baseline Requirements. e.g. a Section in a CA's CPS or a certificate template file used by CA software.
Control: "Control" (and its correlative meanings, "controlled by" and "under common control with") means possession, directly or indirectly, of the power to: (1) direct the management, personnel, finances, or plans of such entity; (2) control the election of a majority of the directors ; or (3) vote that portion of voting shares required for "control" under the law of the entity's Jurisdiction of Incorporation or Registration but in no case less than 10%.
Country: Either a member of the United Nations OR a geographic region recognized as a Sovereign State by at least two UN member nations.
Cross-Certified Subordinate CA Certificate: A certificate that is used to establish a trust relationship between two CAs.
CSPRNG: A random number generator intended for use in a cryptographic system.
Delegated Third Party: A natural person or Legal Entity that is not the CA, and whose activities are not within the scope of the appropriate CA audits, but is authorized by the CA to assist in the Certificate Management Process by performing or fulfilling one or more of the CA requirements found herein.
DNS CAA Email Contact: The email address defined in section Section A.1.1. Appendix A to the BR.
DNS CAA Phone Contact: The phone number defined in Section A.1.2. Appendix A to the BR.
DNS TXT Record Email Contact: The email address defined in Section A.2.1. Appendix A to the BR.
DNS TXT Record Phone Contact: The phone number defined in section Section A.2.2. Appendix A to the BR.
Domain Authorization Document: Documentation provided by, or a CA's documentation of a communication with, a Domain Name Registrar, the Domain Name Registrant, or the person or entity listed in WHOIS as the Domain Name Registrant (including any private, anonymous, or proxy registration service) attesting to the authority of an Applicant to request a Certificate for a specific Domain Namespace.
Domain Contact: The Domain Name Registrant, technical contact, or administrative contact (or the equivalent under a ccTLD) as listed in the WHOIS record of the Base Domain Name or in a DNS SOA record, or as obtained through direct contact with the Domain Name Registrar.
Domain Label: From RFC 8499 (http://tools.ietf.org/html/rfc8499): "An ordered list of zero or more octets that makes up a portion of a domain name. Using graph theory, a label identifies one node in a portion of the graph of all possible domain names."
Domain Name: An ordered list of one or more Domain Labels assigned to a node in the Domain Name System.
Domain Namespace: The set of all possible Domain Names that are subordinate to a single node in the Domain Name System.
Domain Name Registrant: Sometimes referred to as the "owner" of a Domain Name, but more properly the person(s) or entity(ies) registered with a Domain Name Registrar as having the right to control how a Domain Name is used, such as the natural person or Legal Entity that is listed as the "Registrant" by WHOIS or the Domain Name Registrar.
Domain Name Registrar: A person or entity that registers Domain Names under the auspices of or by agreement with: (i) the Internet Corporation for Assigned Names and Numbers (ICANN), (ii) a national Domain Name authority/registry, or (iii) a Network Information Center (including their affiliates, contractors, delegates, successors, or assignees).
Enterprise RA: An employee or agent of an organization unaffiliated with the CA who authorizes issuance of Certificates to that organization.
Expiry Date: The "Not After" date in a Certificate that defines the end of a Certificate's validity period.
Fully-Qualified Domain Name: A Domain Name that includes the Domain Labels of all superior nodes in the Internet Domain Name System.
Government Entity: A government-operated legal entity, agency, department, ministry, branch, or similar element of the government of a country, or political subdivision within such country (such as a state, province, city, county, etc.).
High Risk Certificate Request: A Request that the CA flags for additional scrutiny by reference to internal criteria and databases maintained by the CA, which may include names at higher risk for phishing or other fraudulent usage, names contained in previously rejected certificate requests or revoked Certificates, names listed on the Miller Smiles phishing list or the Google Safe Browsing list, or names that the CA identifies using its own risk-mitigation criteria.
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: The Private Key and its associated Public Key.
LDH Label: From RFC 5890 (http://tools.ietf.org/html/rfc5890): "A string consisting of ASCII letters, digits, and the hyphen with the further restriction that the hyphen cannot appear at the beginning or end of the string. Like all DNS labels, its total length must not exceed 63 octets."
Legal Entity: An association, corporation, partnership, proprietorship, trust, government entity or other entity with legal standing in a country's legal system.
Non-Reserved LDH Label: From RFC 5890
(http://tools.ietf.org/html/rfc5890): "The set of valid LDH labels that do not
have '--' in the third and fourth positions."
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 the CA 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.
Parent Company: A company that Controls a Subsidiary Company.
P-Label: A XN-Label that contains valid output of the Punycode algorithm (as defined in RFC 3492, Section 6.3) from the fifth and subsequent positions.
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.
Pending Prohibition: The use of a behavior described with this label is highly discouraged, as it is planned to be deprecated and will likely be designated as MUST NOT in the future.
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.
Public Key Infrastructure: A set of hardware, software, people, procedures, rules, policies, and obligations used to facilitate the trustworthy creation, issuance, management, and use of Certificates and keys based on Public Key Cryptography.
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.
Registered Domain Name: A Domain Name that has been registered with a Domain Name Registrar.
Registration Authority (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.
Reliable Method of Communication: A method of communication, such as a postal/courier delivery address, telephone number, or email address, that was verified using a source other than the Applicant Representative.
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 database containing publicly-disclosed PKI governance documents (such as Certificate Policies and Certification Practice Statements) and Certificate status information, either in the form of a CRL or an OCSP response.
Request Token: A value, derived in a method specified by the CA which binds this demonstration of control to the certificate request. The CA SHOULD define within its CPS (or a document clearly referenced by the CPS) the format and method of Request Tokens it accepts.
The Request Token SHALL incorporate the key used in the certificate request.
A Request Token MAY include a timestamp to indicate when it was created.
A Request Token MAY include other information to ensure its uniqueness.
A Request Token that includes a timestamp SHALL remain valid for no more than 30 days from the time of creation.
A Request Token that includes a timestamp SHALL be 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 the CA SHALL NOT re-use it for a subsequent validation.
The binding SHALL use a digital signature algorithm or a cryptographic hash algorithm at least as strong as that to be used in signing the certificate request.
Note: Examples of Request Tokens include, but are not limited to: (i) a hash of the public key; or (ii) a hash of the Subject Public Key Info [X.509]; or (iii) a hash of a PKCS#10 CSR. A Request Token may also be concatenated with a timestamp or other data. If a CA wanted to always use a hash of a PKCS#10 CSR as a Request Token and did not want to incorporate a timestamp and did want to allow certificate key re-use then the applicant might use the challenge password in the creation of a CSR with OpenSSL to ensure uniqueness even if the subject and key are identical between subsequent requests.
Required Website Content: Either a Random Value or a Request Token, together with additional information that uniquely identifies the Subscriber, as specified by the CA.
Requirements: The Baseline Requirements found in this document.
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
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.
Sovereign State: A state or country that administers its own government, and is not dependent upon, or subject to, another power.
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.
Subject Identity Information: Information that identifies the Certificate Subject. Subject Identity Information does not include a Domain Name listed in the subjectAltName extension or the Subject commonName field.
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: An agreement between the CA and the Applicant/Subscriber that specifies the rights and responsibilities of the parties.
Subsidiary Company: A company that is controlled by 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 these Requirements when the Applicant/Subscriber is an Affiliate of the CA or is the CA.
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.
Trustworthy System: Computer hardware, software, and procedures that are: reasonably secure from intrusion and misuse; provide a reasonable level of availability, reliability, and correct operation; are reasonably suited to performing their intended functions; and enforce the applicable security policy.
Unregistered Domain Name: A Domain Name that is not a Registered Domain Name.
Valid Certificate: A Certificate that passes the validation procedure specified in RFC 5280.
Validation Specialist: Someone who performs the information verification duties specified by these Requirements.
Validity Period: From RFC 5280 (http://tools.ietf.org/html/rfc5280): "The period of time from notBefore through notAfter, inclusive."
WHOIS: Information retrieved directly from the Domain Name Registrar or registry operator via the protocol defined in RFC 3912, the Registry Data Access Protocol defined in RFC 7482, or an HTTPS website.
**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 (http://tools.ietf.org/html/rfc5890): "The class of labels that begin with the prefix "xn--" (case independent), but otherwise conform to the rules for LDH labels."
AICPA, American Institute of Certified Public Accountants
ADN, Authorization Doman Name
BR, CA/Browser Forum Baseline Requirements
CA, Certificate Authority
CAA, Certificate Authority Authorization
ccTLD, Country Code Top‐Level Domain
CICA, Canadian Institute of Chartered Accountants
CP, Certificate Policy
CPS, Certification Practice Statement
CRL, Certificate Revocation List
DBA, Doing Business As
DNS, Domain Name System
FIPS, (US Government) Federal Information Processing Standard
FQDN, Fully-Qualified Domain Name
IM, Instant Messaging
IANA, Internet Assigned Numbers Authority
ICANN, Internet Corporation for Assigned Names and Numbers
ISO, International Organization for Standardization
NIST, (US Government) National Institute of Standards and Technology
OCSP, Online Certificate Status Protocol
OID, Object Identifier
PKI, Public Key Infrastructure
RA, Registration Authority
S/MIME, Secure MIME (Multipurpose Internet Mail Extensions) SSL Secure Sockets Layer
TLD, Top‐Level Domain
TLS, Transport Layer Security
VoIP, Voice Over Internet Protocol
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 411‐1, Electronic Signatures and Infrastructures (ESI); Policy and security requirements for Trust Service Providers issuing certificates; Part 1: General requirements.
ETSI TS 102 042, Electronic Signatures and Infrastructures (ESI); Policy requirements for certification authorities issuing public key certificates.
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.
ISO 21188:2006, Public key infrastructure for financial services ‐‐ Practices and policy framework. Network and Certificate System Security Requirements, v.1.0, 1/1/2013.
Network and Certificate System Security Requirements, Version 1.7, available at https://cabforum.org/wp-content/uploads/CA-Browser-Forum-Network-Security-Guidelines-v1.7.pdf.
NIST SP 800-89, Recommendation for Obtaining Assurances for Digital Signature Applications, https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-89.pdf.
RFC2119, Request for Comments: 2119, Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. March 1997.
RFC3492, Request for Comments: 3492, Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA). A. Costello. March 2003.
RFC3647, Request for Comments: 3647, Internet X.509 Public Key Infrastructure: Certificate Policy and Certification Practices Framework. S. Chokhani, et al. November 2003.
RFC3912, Request for Comments: 3912, WHOIS Protocol Specification. L. Daigle. September 2004.
RFC3986, Request for Comments: 3986, Uniform Resource Identifier (URI): Generic Syntax. T. Berners-Lee, et al. January 2005.
RFC5019, Request for Comments: 5019, The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments. A. Deacon, et al. September 2007.
RFC5280, Request for Comments: 5280, Internet X.509 Public Key Infrastructure: Certificate and Certificate Revocation List (CRL) Profile. D. Cooper, et al. May 2008.
RFC5322, Request for Comments: 5322, Internet Message Format, Resnick, October 2008.
RFC5890, Request for Comments: 5890, Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework. J. Klensin. August 2010.
RFC5952, Request for Comments: 5952, A Recommendation for IPv6 Address Text Representation. S. Kawamura, et al. August 2010.
RFC8499, Request for Comments: 8499, DNS Terminology. P. Hoffman, et al. January 2019.
RFC6960, Request for Comments: 6960, X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP. S. Santesson, et al. June 2013.
RFC6962, Request for Comments: 6962, Certificate Transparency. B. Laurie, et al. June 2013.
RFC7482, Request for Comments: 7482, Registration Data Access Protocol (RDAP) Query Format. A. Newton, et al. March 2015.
RFC7538, Request For Comments: 7538, The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect). J. Reschke. April 2015.
RFC8659, Request for Comments: 8659, DNS Certification Authority Authorization (CAA) Resource Record. P. Hallam-Baker, et al. November 2019.
WebTrust for Certification Authorities, SSL Baseline with Network Security, Version 2.5, available at https://www.cpacanada.ca/-/media/site/operational/ms-member-services/docs/webtrust/wt100bwtbr-25-110120-finalaoda.pdf.
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.
| Version | Date | Change owner | Note |
|---|---|---|---|
| 1.0 | 2016-12-09 | CA Policy Authority | Initial publication |
| 1.1 | 2017-02-15 | CA Policy Authority | Updated contact information |
| 1.2 | 2017-05-29 | CA Policy Authority | Updated certificate operational periods |
| 1.3 | 2017-09-08 | CA Policy Authority | Aligned with new version of CA/B Forum Requirements |
| 1.4 | 2018-03-08 | CA Policy Authority | Aligned with new version of CA/B Forum Requirements |
| 1.5 | 2018-05-08 | CA Policy Authority | Applied changes of CA/B Forum Ballot 220 |
| 1.6 | 2018-10-23 | CA Policy Authority | Updated validation methods and revocation timelines |
| 1.7 | 2019-01-07 | CA Policy Authority | Added prohibition of underscore characters in dNSName entries |
| 1.8 | 2019-05-08 | CA Policy Authority | Updated section on Subscribers |
| 1.9 | 2019-05-14 | CA Policy Authority | Aligned with BR version 1.6.5 |
| 1.10 | 2020-06-02 | CA Policy Authority | Aligned with BR version 1.7.0 |
| 1.11 | 2020-06-05 | CA Policy Authority | Clarified OID requirements in Section 1.2 |
| 1.12 | 2020-08-21 | CA Policy Authority | Clarified OID requirements in Section 1.2 |
| 1.13 | 2020-11-09 | CA Policy Authority | Aligned with BR version 1.7.3 |
| 2.0 | 2021-03-19 | CA Policy Authority | Updated various sections following annual CP review |
| 2.1 | 2021-05-10 | CA Policy Authority | Updated various sections following annual CP review |
| 3.0 | 2021-08-11 | CA Policy Authority | Updated various sections following full CP review |
| 3.1 | 2021-09-09 | CA Policy Authority | Updated additional section following full CP review. |
| 3.2 | 2021-12-02 | CA Policy Authority | Updated various sections based on ballot SC48 |
| 3.3 | 2023-02-16 | CA Policy Authority | Clarified that CT Poison and SCT extensions are used in our certificates |
| 3.4 | 2023-02-21 | CA Policy Authority | Updated various sections based on ballot SC-56 and SC-58 |
| 3.5 | 2023-04-26 | CA Policy Authority | SC-61: New CRL Entries must have a Revocation Reason Code |
| 3.6 | 2023-08-28 | CA Policy Authority | SC-62: Certificate Profiles Update |