The Google Public Key Infrastructure (“Google PKI”) has been established 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 issuance and management of S/MIME Certificates within the Google PKI. It sets forth the business, legal, and technical requirements for approving, issuing, managing, using, revoking, and renewing, Google S/MIME Certificates and providing associated trust services for all Participants. This CP has been published to protect the security and integrity of the Google PKI.
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 S/MIME Certificates (S/MIME BR) in their current version.
All CAs subject to this CP SHALL give effect to the S/MIME BR in their current version and indicate their applicability in the CPS. In the event of any inconsistency between this CP and the S/MIME BR, the S/MIME BR take precedence.
Google has reserved the following Object Identifiers (OIDs) for its S/MIME issuance policies.
| Issuance Policy | Google Object Identifier (Google OID) |
|---|---|
| This Certificate Policy (CP) | 1.3.6.1.4.1.11129.2.5.4 |
| S/MIME | 1.3.6.1.4.1.11129.2.5.4.1 |
All Certificates issued in accordance with the S/MIME BR shall include one of the following CA/B Forum Policy Identifiers:
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 Google Certificates that assert at least one of the CA/Browser Forum's reserved S/MIME policy OIDs defined above. By including one of the above Google policy OIDs, Google 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) |
|---|---|---|
| 2023-09-01 | All | Version 1.0.1 of the S/MIME BR goes into effect |
Google issues public key certificates within the Google PKI as a Certification Authority (CA) through two entities. The certificates are issued by or on behalf of Google Trust Services Europe Ltd for Subscribers in the EU and by Google Trust Services LLC for all other Subscribers. References to "Google" in this CP will refer to the applicable Google Trust Services entity that issues the certificates.
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 Registration Authority (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 in accordance with Section 8.8.
An Enterprise RA MAY also submit Certificate Requests using the Mailbox-validated profile for users whose email domain(s) are not under the delegated organization’s authorization or control. In this case, the CA SHALL confirm that the mailbox holder has control of the requested Mailbox Address(es) in accordance with Section 3.2.2.2.
See Appendix C.
See Appendix C.
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.
The Google CA Policy Authority is responsible for the drafting, maintenance, and interpretation of this Certificate Policy.
Google Trust Services LLC
CA Policy Authority
1600 Amphitheatre Parkway
Mountain View, CA 94043
USA \
Google Trust Services Europe Ltd
70 SIR JOHN ROGERSON'S QUAY
DUBLIN, D02R296
Ireland \
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/.
The Google CA Policy Authority determines the suitability of CPS documents published in response to this CP.
Approvals of this CP and any amendments thereof are made by the Google CA Policy Authority. Amendments SHALL be made by publishing a new version of this CP at https://pki.goog/repository/.
New versions of this CP become effective upon posting.
This CP and associated documents are available from the Repository at https://pki.goog/repository/.
See Appendix C.
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this CP shall be interpreted in accordance with RFC 2119.
The CA SHALL make revocation information for Subordinate CA Certificates and Subscriber Certificates available in accordance with this Policy.
The CA SHALL publicly disclose its CPS 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).
The CPS SHALL be structured in accordance with RFC 3647 and SHALL include all material required by RFC 3647.
The CA SHALL publicly give effect to the Baseline Requirements for the Issuance and Management of Publicly‐Trusted S/MIME Certificates and represent that it will adhere to the latest published version. The CA MAY fulfill this requirement by incorporating the Baseline Requirements directly into its CP and/or CPS or by incorporating them by reference.
The CA SHALL develop, implement, enforce, and annually update a CPS that describes in detail how the CA implements the latest version of the Baseline Requirements. The CA SHALL review and update its CPS at least every 365 days, 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.
When the subject:commonName of a Certificate issued to an Individual does not
contain a Mailbox Address, it is specified as a Personal Name or Pseudonym as
described in Section 7.1.4.2.2 (a).
Names consisting of multiple words are permitted. Given names joined with a hyphen are considered as one single given name. Subjects with more than one given name MAY choose one or several of their given names in any sequence. Subjects MAY choose the order of their given name(s) and surname in accordance with national preference.
The CA MAY allow common variations or abbreviations of Personal Names consistent with local practice.
Personal Names SHALL be a meaningful representation of the Subject’s name as verified in the identifying documentation or Enterprise RA records.
The purpose of a Pseudonym is to provide a unique identifier linked to an Individual in a pseudonymized manner when certain privacy conditions are required. For example, a Pseudonym may be used if a government agency requires officials to sign certain decisions via S/MIME so those decisions trace back to individuals, but emphasize the importance of the role over Individual identity in the Certificate. The CA SHALL disclose in its CPS if it allows the use of Pseudonyms.
For Sponsor-validated Certificates, the CA MAY use a subject:pseudonym
attribute in the Certificate if the associated Subject has been verified
according to Section 3.2.4. If present, the subject:pseudonym attribute SHALL
be:
subject:organizationName attribute.For Individual-validated Certificates, the CA MAY use the subject:pseudonym
attribute if the associated Subject has been verified according to Section
3.2.4. If present, the subject:pseudonym attribute SHALL be:
Pseudonym Certificates are not anonymous. CAs and Enterprise RAs SHALL treat Individual identity information relating to a Pseudonym as private in accordance with Section 9.4.2.
The CA MAY allow the Conversion of Subject Identity Information usually rendered in non-ASCII characters (including Accent or Umlaut-accented characters) using a system commonly used in the Applicant's Jurisdiction of Incorporation or Registration, or recognized by the United Nations or the International Organization for Standardization (ISO). The CA SHOULD state the used Conversion systems in its CPS. For example, regardless of capitalization:
The CA MAY include an ASCII character name that is not a direct Conversion of the Applicant's registered name provided that it is verified in a Reliable Data Source or suitable Attestation.
The CA MAY use geographic endonyms and exonyms in the subject:localityName and
subject:stateOrProvinceName attributes, (e.g., Munich, Monaco di Bavaria, or
Мюнхен for München). The CA SHOULD avoid the use of archaic geographic names,
(e.g., prefer Mumbai over Bombay).
No stipulation.
No stipulation.
The CA SHALL authenticate the identity attributes of the Subject and their control over the Mailbox Addresses to be included in the Certificate according to the requirements of the following sections:
| Certificate Type | Mailbox | Organization | Individual |
: : Control : Identity : Identity :
| ------------------------ | ------------- | ------------- | ------------- |
| Mailbox-validated | Section 3.2.2 | NA | NA |
| Organization-validated | Section 3.2.2 | Section 3.2.3 | NA |
| Sponsor-validated | Section 3.2.2 | Section 3.2.3 | Section 3.2.4 |
| Individual-validated | Section 3.2.2 | NA | Section 3.2.4 |
No stipulation.
This section defines the permitted processes and procedures for confirming the Applicant's control of Mailbox Addresses to be included in issued Certificates.
The CA SHALL verify that Applicant controls the email accounts associated with all Mailbox Fields referenced in the Certificate or has been authorized by the email account holder to act on the account holder’s behalf.
The CA SHALL NOT delegate the verification of mailbox authorization or control.
The CA's CPS SHALL specify the procedures that the CA employs to perform this verification. CAs SHALL maintain a record of which validation method, including the relevant version number from the TLS Baseline Requirements or S/MIME Baseline Requirements, was used to validate every domain or email address in issued Certificates.
Completed validations of Applicant authority MAY be valid for the issuance of multiple Certificates over time. In all cases, the validation SHALL have been initiated within the time period specified in the relevant requirement (such as Section 4.2.1) prior to Certificate issuance.
The CA MAY confirm the Applicant, such as an Enterprise RA, has been authorized by the email account holder to act on the account holder’s behalf by verifying the entity's control over the domain portion of the Mailbox Address to be used in the Certificate.
The CA SHALL use only the approved methods in Section 3.2.2.4 of the TLS Baseline Requirements to perform this verification.
For purposes of domain validation, the term Applicant includes the Applicant's Parent Company, Subsidiary Company, or Affiliate.
The CA MAY confirm the Applicant's control over each Mailbox Field to be included in a Certificate by sending a Random Value via email and then receiving a confirming response utilizing the Random Value.
Control over each Mailbox Address SHALL be confirmed using a unique Random Value. The Random Value SHALL be sent only to the email address being validated and SHALL not be shared in any other way.
The Random Value SHALL be unique in each email. The Random Value SHALL remain valid for use in a confirming response for no more than 24 hours from its creation. The CA MAY specify a shorter validity period for Random Values in its CPS.
The Random Value SHALL be reset upon each instance of the email sent by the CA to a Mailbox Address, however all relevant Random Values sent to that Mailbox Address MAY remain valid for use in a confirming response within the validity period described in this Section. In addition, the Random Value SHALL be reset upon first use by the user if intended for additional use as an authentication factor following the Mailbox Address verification.
The CA MAY confirm the Applicant's control over each Mailbox Field to be included in the Certificate by confirming control of the SMTP FQDN to which a message delivered to the Mailbox Address should be directed. The SMTP FQDN SHALL be identified using the address resolution algorithm defined in RFC 5321 Section 5.1 which determines which SMTP FQDNs are authoritative for a given Mailbox Address. If more than one SMTP FQDN has been discovered, the CA SHALL verify control of an SMTP FQDN following the selection process at RFC 5321 Section 5.1. Aliases in MX record RDATA SHALL NOT be used for this validation method.
To confirm the Applicant's control of the SMTP FQDN, the CA SHALL use only the currently-approved methods in Section 3.2.2.4 of the TLS Baseline Requirements.
This CP does not require the CA to check for CAA records. The CAA property tags
for issue, issuewild, and iodef as specified in
RFC 8659 are not recognized for
the issuance of S/MIME Certificates.
The following requirements SHALL be fulfilled to authenticate Organization
identity included in the Organization-validated and Sponsor-validated
profiles.
The CA or RA SHALL collect and retain evidence supporting the following identity attributes for the Organization:
The unique identifier SHALL be included in the Certificate
subject:organizationIdentifier as specified in Section 7.1.4.2.2 and Appendix
A.
If an Attestation is used as evidence for the validation of the attributes described in this section, then the Attestation SHALL be verified for authenticity as described in Section 3.2.8.
The CA or RA SHALL verify the full legal name and an address (if included in the Certificate Subject) of the Legal Entity Applicant using documentation provided by, or through communication with, at least one of the following:
The CA or RA MAY use the same documentation or communication described in 1 through 4 above to verify both the Applicant's identity and address.
If an LEI data reference is used, the CA or RA SHALL verify that the RegistrationStatus is ISSUED and the EntityStatus is ACTIVE. The CA SHALL only allow use of an LEI if the ValidationSources entry is FULLY_CORROBORATED. An LEI SHALL NOT be used if ValidationSources entry is PARTIALLY_CORROBORATED, PENDING, or ENTITY_SUPPLIED_ONLY.
Applicants MAY request an Assumed Name to be included in the Certificate. The CA or RA SHALL verify that:
The CA MAY rely on an Attestation that indicates the Assumed Name under which the Applicant conducts business, the government agency with which the Assumed Name is registered, and that such filing continues to be valid.
The CA or RA SHALL verify the unique identifier used in the Certificate from a register that is maintained or authorized by the relevant government agency. The CA SHALL disclose the authorized sources it uses to verify the Applicant's creation, existence, or recognition. This disclosure SHALL be through an appropriate and readily accessible online means. The CA SHALL document where to obtain this information within Section 3.2 of the CA's CPS.
Nothing in this CP prohibits the use of third-party vendors to obtain regularly-updated and current information from the government register provided that the third party obtains the information directly from the government.
In the case of a LEI data reference, the CA or RA SHALL verify the associated data record with the Global Legal Entity Identifier Foundation.
The following requirements SHALL be fulfilled to authenticate Individual
identity attributes included in Sponsor-validated and Individual-validated
Certificate profiles.
The CA, RA, or Enterprise RA SHALL collect and retain evidence supporting the following identity attributes for the Individual Applicant:
The CA or RA SHALL comply with applicable data protection legislation in the gathering and retention of evidence relating to Individual identity supporting this Requirement in accordance with Section 9.4.
The CA SHALL document and publish the methods it uses to collect Individual identity attributes.
From a physical identity document
If physical identity documents are used as evidence, the CA or RA SHALL accept only government-issued passports or identity cards, and other official identity documents of comparable reliability (such as drivers license or military ID).
The physical identity document used as evidence SHALL contain a face photo and/or other information that can be compared with the Applicant's physical appearance.
The CA SHALL document and publish information describing the physical or digital identity documents or document types it accepts.
From a digital identity document
If digital identity documents (such as passports or national ID cards including a chip bearing digitally signed information about the holder) are used as evidence, the CA or RA SHALL only accept eMRTD digital identity documents according to ICAO 9303 part 10.
This method does not include "eID" as described in Regulation (EU) 910/2014.
Using electronic identification schemes (eID)
If an eID is used as evidence, the CA or RA SHALL only accept “notified” eID schemes according to Article 9 of the eIDAS Regulation and the eID shall conform to eIDAS LoA “Substantial” or “High”.
The CA SHALL document and publish information describing the eID and associated eID attributes it accepts.
From a Certificate supporting a digital signature applied by the Applicant
If a digital signature is to be used as evidence, the CA or RA SHALL have the Applicant digitally sign the Certificate Request using a valid personal Certificate that was issued under an Approved Framework described in this section.
Identity attributes are evidenced by the signing Certificate, not by the content of the signed document. The CA or RA SHALL only rely upon the signing Certificate as evidence for identity attributes if the digital signature is valid in accordance with the requirements of the relevant Approved Framework.
The CA SHOULD consider requirements to avoid issuance of consecutive Certificates that are issued based on a preceding Certificate, where the original verification of the Subject's identity may have been conducted in the distant past.
Approved Frameworks
From Enterprise RA records
In the case of Sponsor-validated Certificates approved by an Enterprise RA,
records maintained by the Enterprise RA SHALL be accepted as evidence of
Individual identity.
The Enterprise RA SHALL maintain records to satisfy the requirements of Section 1.3.2 and Section 8.8.
Affiliation from company attestation
In the case of Sponsor-validated Certificates not approved by an Enterprise
RA, the CA or RA MAY verify the authority or affiliation of an Individual to
represent an Organization to be included in the subject:organizationName of
the Certificate using an Attestation provided by the Organization and verified
in accordance with Section 3.2.8.
The CA or RA SHALL still verify the identity of the Individual in accordance with Section 3.2.4 and the Organization in accordance with Section 3.2.3.
From a general attestation
Evidence for Individual identity attributes MAY be gathered using an Attestation from a qualified legal practitioner or notary in the Applicant's jurisdiction.
From authorized reference sources as supplementary evidence
Evidence for Individual identity attributes SHALL use at least one of the following sources for authoritative evidence: a physical or digital identity document, digital signature supported by Certificate, Enterprise RA records, or suitable Attestation.
The CA or RA MAY additionally gather and verify supplementary evidence using authorized sources such as additional official documents, government or regulatory registers, or national population registers.
Examples of this method include:
subject:country,
or a corporate Title linked to the subject:organizationName, is to be used
it SHALL be verified against supporting documentation, a Reliable Data
Source, or Attestation.Sponsor-validated Certificate, the CA SHALL verify that the LEI is
assigned to the Individual and the subject:organizationName in the
Certificate Subject.The CA SHALL internally document the accepted reference sources, including a description of the documents or Attestations accepted as supplementary evidence.
The CA or RA SHALL validate all identity attributes of the Individual to be included in the Certificate.
If the evidence has an explicit validity period, the CA SHALL verify that the
time of the identity validation is within this validity period. In context this
can include the notBefore and notAfter fields of a digital signature
Certificate or the date of expiry of an identity document.
The CA or RA MAY reuse existing evidence to validate Individual identity subject to the age restrictions in Section 4.2.1.
Validation of a physical identity document
The physical identity document SHALL be presented in its original form. The CA SHALL employ procedures to ensure the evidence presented by the Applicant is a genuine identity document that is not counterfeited or falsified/modified.
The CA or RA MAY use manual (in person) or remote procedures. A remote process SHALL ensure that the Applicant has the document in hand and presents the document in real-time in front of a camera.
The CA or RA registration agent SHALL make a visual comparison of the physical appearance of the Applicant and the face photo and/or other information on the physical identity document.
The CA or RA registration agent SHALL have access to authoritative sources of information on document appearance and validation for forms of identity document accepted by the CA.
The CA or RA SHALL retain information sufficient to evidence the fulfillment of the identity validation process and the verified attributes. In addition to identity attributes, the CA or RA SHALL record the following information: issuer, validity period, and the document's unique identification number.
Automated and manual processes MAY be used in combination, (for example the CA or RA may deploy automated tools to support the work of a registration agent, or an automated process that falls back to a registration agent if the process yields an uncertain result).
Validation of a digital identity document
The CA or RA SHALL only accept digital identity documents if the issuer's digital signature on the document is successfully validated according to ICAO 9303 part 11.
The CA or RA SHALL record information obtained from the digital identity document to evidence the identity proofing process. In addition to identity attributes and face photo, the following information SHALL be recorded: issuer, validity period, and the document's unique identification number.
The CA or RA registration agent SHALL make a visual comparison of the physical appearance of the Applicant and the face photo and/or other information on the digital identity document.
Automated and manual processes MAY be used in combination, (for example using automated tools to support the work of a registration agent, or an automated process that falls back to a registration agent if the process yields an uncertain result).
Validation of eID
If authentication using an eID is used as evidence, the CA or RA SHALL confirm that the eID scheme is suitable (i.e., that the eID is accessible via a "notified" eIDAS-Node), and that the individual eID is valid (i.e., not expired, suspended, or revoked).
The authentication using the eID SHALL be created as part of the identity validation process, and evidence of the validation with the eID's Identity Provider (IdP) SHALL be retained by the CA or RA.
Validation of digital signature with Certificate
If a digital signature with Certificate is used as evidence, the signature SHALL be created as part of the identity validation process.
The CA or RA SHALL validate the digital signature and SHALL only use the signing Certificate as evidence for identity attributes if the signature is valid.
If required identity attributes to be collected are not present in the Certificate, the CA or RA SHALL collect these attributes from other sources and validate them accordingly.
Validation of an Attestation
If an Attestation is used as evidence for the validation of Individual identity attributes, then the reliability of the Attestation SHALL be verified according to Section 3.2.8.
Validation using an Enterprise RA record
An Enterprise RA issuing a Sponsor-validated Certificate SHALL validate all identity attributes of an Individual to be included in the Certificate. The Enterprise RA MAY rely upon existing internal records to validate Individual identity.
Subscriber information that has not been verified in accordance with this CP SHALL NOT be included in Publicly-Trusted Certificates.
Before commencing to issue Organization-validated and Sponsor-validated
Certificates for an Applicant, the CA or RA SHALL use a Reliable Method of
Communication to verify the authority and approval of an Applicant
Representative to perform one or more of the following:
The CA or RA MAY establish a process that allows an Applicant to specify the individuals who may act as Applicant Representatives on an ongoing basis. The CA SHALL provide an Applicant with a list of its authorized Applicant Representatives upon the Applicant's verified written request.
The CA or RA MAY use the sources listed in Section 3.2.3.2.1 to verify the Reliable Method of Communication. Provided that the CA or RA uses a Reliable Method of Communication, the CA or RA 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 or RA deems appropriate.
The CA SHALL disclose all Cross 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 Certificate at issue).
Before relying on a source of verification data to validate Certificate Requests, the CA SHALL verify its suitability as a Reliable Data Source. Enterprise RA records are a Reliable Data Source for Individual Subject attributes included in Sponsor-validated Certificates issued to the Enterprise RA’s Organisation.
The CA or RA MAY rely upon a letter attesting that Subject Information or other fact is correct. The CA or RA SHALL verify that the letter was written by an accountant, lawyer, government official, or other reliable third party in the Applicant’s jurisdiction customarily relied upon for such information.
An Attestation SHALL include a copy of documentation supporting the fact to be attested. The CA or RA SHALL use a Reliable Method of Communication to contact the sender and to confirm the Attestation is authentic.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
Prior to the issuance of a Certificate, the CA SHALL obtain the following documentation from the Applicant:
The Certificate Request and Subscriber Agreement or Terms of Use SHALL be in a form prescribed by the CA and SHALL comply with this CP including Section 9.6.3. The CA SHOULD obtain any additional documentation the CA determines necessary to fulfill the requirements defined in this CP.
The Certificate Request SHALL 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.
One Certificate Request MAY suffice for multiple Certificates to be issued to the same Applicant, subject to the validation reuse periods described 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.
A CA may rely on a previously verified Certificate Request to issue a replacement Certificate if:
Applicant information SHALL include, but not be limited to, at least one Mailbox
Field to be included in the Certificate's subjectAltName extension.
Section 6.3.2 limits the validity period of Subscriber Certificates.
The CA MAY reuse completed validations and/or supporting evidence performed in accordance with Section 3.2 within the following limits:
Validation of mailbox authorization or control: Completed validation of the control of a mail server in accordance with Section 3.2.2.1 or Section 3.2.2.3 SHALL be obtained no more than 398 days prior to issuing the Certificate.
In the event of changes to the TLS Baseline Requirements methods specified in Section 3.2.2.1, a CA MAY continue to reuse completed validations and/or supporting evidence for the period stated in this section.
Completed validation of control of a mailbox in accordance with Section 3.2.2.2 SHALL be obtained no more than 30 days prior to issuing the Certificate.
Authentication of organization identity: Completed validation of organization identity in accordance with Section 3.2.3 SHALL be obtained no more than 825 days prior to issuing the Certificate.
Validation of authority in accordance with Section 3.2.6 SHALL be obtained no more than 825 days prior to issuing the Certificate, unless a contract between the CA and the Applicant specifies a different term. For example, the contract MAY include the perpetual assignment of roles until revoked by the Applicant or CA, or until the contract expires or is terminated.
Authentication of individual identity: Completed validation of Individual identity in accordance with Section 3.2.4 SHALL be obtained no more than 825 days prior to issuing the Certificate.
A prior validation SHALL NOT 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.
No stipulation.
No stipulation.
Certificate issuance by the Root CA SHALL require at least two individuals authorized by the CA (i.e., the CA system operator, system officer, or PKI administrator) one of whom deliberately issues 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.
No stipulation.
The CA SHALL revoke a Certificate within 24 hours if one or more of the following occurs:
The CA SHOULD revoke a Certificate within 24 hours and SHALL revoke a Certificate within 5 days 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 a Certificate.
The CA SHALL provide a process for Subscribers to request revocation of their own Certificates. The process SHALL be described in the CA's CPS. The CA SHALL maintain a continuous 24x7 ability to accept and respond to revocation requests and Certificate Problem Reports.
The CA SHALL provide 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 on which the CA will revoke the Certificate. The period from receipt of the Certificate Problem Report or revocation-related notice to published revocation SHALL 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 reasons 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: the CA SHALL update and reissue CRLs
at least once every seven days, and the value of the nextUpdate field SHALL
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:
The value of the nextUpdate field SHALL NOT be more than twelve months beyond
the value of the thisUpdate field.
No stipulation.
When provided, OCSP responses SHALL conform to RFC 6960 and/or RFC 5019. OCSP responses SHALL either:
In the latter case, the OCSP signing Certificate SHALL contain the ocspSigning
EKU (1.3.6.1.5.5.7.3.9) and an extension of type id-pkix-ocsp-nocheck, as
defined by RFC 6960.
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, the CA SHALL update information provided via OCSP:
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.5, the responder SHALL 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.
A Certificate serial number within an OCSP request is "assigned" if a Certificate with that serial number has been issued by the Issuing CA, using any current or previous key associated with that CA subject, or "unused" if otherwise.
No stipulation.
See Section 4.9.1.
See Section 7.2.2 for restrictions on use of suspension. The CA SHALL describe its suspension practices in the CA's CPS.
No stipulation.
No stipulation.
No stipulation.
Revocation entries on a CRL or OCSP Response SHALL 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.
The CA MAY escrow the Subscriber’s Private Key as specified in the CA's CPS.
The CA SHALL notify Subscribers when their Private Keys are escrowed. Escrowed Private Keys SHALL be stored in encrypted form. The CA SHALL protect escrowed Private Keys from unauthorized disclosure.
The CA SHALL recover Subscriber Private Keys only under the circumstances permitted within the CA's CPS.
No stipulation.
The CA SHALL develop, implement, and maintain a comprehensive security program designed to:
The Certificate Management Process SHALL include:
The CA's security program SHALL include an annual Risk Assessment that:
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 SHALL include administrative, organizational, technical, and physical safeguards appropriate to the sensitivity of the Certificate Data and Certificate Management Processes. The security plan SHALL 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.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
The CA 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 CP and/or CPS) and common threats to the information verification process (including phishing and other social engineering tactics).
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 this CP.
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 events related to the security of their Certificate Systems, Certificate Management Systems, Root CA Systems, and Delegated Third Party Systems. The CA and each Delegated Third Party SHALL record events related to their 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 this CP.
The CA SHALL record at least the following events:
CA Certificate and key lifecycle events, including:
i. Key generation, backup, storage, recovery, archival, and destruction;
ii. Certificate requests, renewal, and re-key requests, and revocation;
iii. Approval and rejection of Certificate Requests;
iv. Cryptographic device lifecycle management events;
v. Generation of Certificate Revocation Lists;
vi. Signing of OCSP Responses (as described in Section 4.9 and Section 4.10); and
vii. Introduction of new Certificate Profiles and retirement of existing Certificate Profiles.
Subscriber Certificate lifecycle management events, including:
i. Certificate requests, renewal, and re-key requests, and revocation;
ii. All verification activities stipulated in this CP and the CA's Certification Practice Statement;
iii. Approval and rejection of Certificate Requests;
iv. Issuance of Certificates;
v. Generation of Certificate Revocation Lists; and
vi. Signing of OCSP Responses (as described in Section 4.9 and Section 4.10).
Security events, including:
i. Successful and unsuccessful PKI system access attempts;
ii. PKI and security system actions performed;
iii. Security profile changes;
iv. Installation, update and removal of software on a Certificate System;
v. System crashes, hardware failures, and other anomalies;
vi. Firewall and router activities; and
vii. Entries to and exits from the CA facility.
Log records SHALL include the following elements:
No stipulation.
The CA and each Delegated Third Party SHALL retain, for at least two (2) years:
basicConstraints extension with the cA field set to true and which share a common Public Key corresponding to the CA Private Key;No stipulation.
No stipulation.
No stipulation.
No stipulation.
The CA's security program SHALL include an annual Risk Assessment that:
The CA and each Delegated Third Party SHALL archive all audit logs (as set forth in Section 5.4.1).
Additionally, the CA and each Delegated Third Party SHALL archive:
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 as long as they are required to be retained per Section 5.4.3, whichever is longer.
Additionally, the CA and each Delegated Third Party SHALL retain, for at least two (2) years:
No stipulation.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
CA operators SHALL have an Incident Response Plan and a Disaster Recovery Plan.
The CA SHALL document a business continuity and disaster recovery procedures 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 SHALL include:
No stipulation.
No stipulation.
No stipulation.
No stipulation.
For CA Key Pairs that are either
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:
No stipulation.
The CA SHALL reject a Certificate Request if one or more of the following conditions are met:
The CA or a Delegated Third Party MAY generate the Private Key on behalf of the Subscriber.
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 a person or organization not authorized by the Subscriber, then the CA SHALL revoke all Certificates that include the Public Key corresponding to the communicated Private Key.
If the CA or a Delegated Third Party generates the Private Key on behalf of the Subscriber where the Private Keys will be transported to the Subscriber, then the entity generating the Private Key SHALL either transport the Private Key in hardware with an activation method that is equivalent to 128 bits of encryption or encrypt the Private Key with at least 128 bits of encryption strength. Example methods include using a 128-bit AES key to wrap the Private Key or storing the key in a PKCS 12 file encrypted with a randomly generated password of more than 16 characters containing uppercase letters, lowercase letters, numbers, and symbols for transport. The CA or Delegated Third Party SHALL NOT store Subscriber Private Keys in clear text.
The material used to activate/protect the Private Key (e.g., a password used to secure a PKCS 12 file) must be delivered to the Subscriber securely and separately from the container holding the Private Key.
No stipulation.
No stipulation.
For RSA key pairs the CA SHALL:
For ECDSA key pairs, the CA SHALL:
For EdDSA key pairs, the CA SHALL:
No other algorithms or key sizes are permitted.
For RSA key pairs: 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. (See NIST SP 800-89, Section 5.3.3.)
For ECDSA key pairs: 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. (See NIST SP 800-56A: Revision 2, Sections 5.6.2.3.2 and 5.6.2.3.3.)
For EdDSA key pairs: no stipulation.
Private Keys corresponding to Root CA Certificates SHALL 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 CA Private Key outside the validated system or device specified above SHALL 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.
| Generation | Maximum Validity Period |
|---|---|
| Strict and Multipurpose | 825 days |
| Legacy | 1185 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.
The CA/Browser Forum's Network and Certificate System Security Requirements are incorporated by reference as if fully set forth herein.
No stipulation.
The CA SHALL meet the technical requirements set forth in Section 2.2, Section 6.1.5, and Section 6.1.6.
CAs SHALL generate non-sequential Certificate serial numbers greater than zero (0) and less than 2^159 containing at least 64 bits of output from a CSPRNG.
Certificates SHALL be of type X.509 v3.
This section specifies the additional requirements for Certificate content and extensions for Certificates.
a. basicConstraints (SHALL be present)
This extension SHALL be marked critical. The cA field SHALL be set true. The
pathLenConstraint field SHOULD NOT be present.
b. keyUsage (SHALL be present)
This extension SHALL be marked critical. Bit positions for keyCertSign and
cRLSign SHALL be set. If the Root CA Private Key is used for signing OCSP
responses, then the digitalSignature bit SHALL be set.
c. certificatePolicies (SHOULD NOT be present)
This extension SHOULD NOT be present.
d. extKeyUsage (SHALL NOT be present)
This extension SHALL NOT be present.
e. subjectKeyIdentifier (SHALL be present)
This extension SHALL NOT be marked critical. It SHALL contain a value that is
included in the keyIdentifier field of the authorityKeyIdentifier extension
in Certificates issued by the Root CA.
The issuance of end entity Certificates by Extant S/MIME CAs is described in Appendix B.
a. certificatePolicies (SHALL be present)
This extension SHOULD NOT be marked critical.
All policyIdentifiers included in this extension SHALL be included in
accordance with Section 7.1.6.3.
If the value of this extension includes a PolicyInformation which contains a
qualifier of type id-qt-cps (OID: 1.3.6.1.5.5.7.2.1), then the value of the
qualifier SHALL be a HTTP or HTTPS URL for the Issuing CA's CPS, Relying Party
Agreement, or other pointer to online policy information provided by the Issuing
CA. If a qualifier of type id-qt-unotice (OID: 1.3.6.1.5.5.7.2.2) is included,
then it SHALL contain explicitText and SHALL NOT contain noticeRef.
b. cRLDistributionPoints (SHALL be present)
This extension SHALL NOT be marked critical. It SHALL contain the HTTP URL of the CA's CRL service.
c. authorityInformationAccess (SHOULD be present)
This extension SHALL NOT be marked critical.
It SHOULD contain the HTTP URL of the Issuing CA Certificate (accessMethod =
1.3.6.1.5.5.7.48.2). It MAY contain the HTTP URL of the Issuing CA OCSP
responder (accessMethod = 1.3.6.1.5.5.7.48.1).
d. basicConstraints (SHALL be present)
This extension SHALL be marked critical. The cA field SHALL be set true. The
pathLenConstraint field MAY be present.
e. keyUsage (SHALL be present)
This extension SHALL be marked critical. Bit positions for keyCertSign and
cRLSign SHALL be set. If the Subordinate CA Private Key is used for signing
OCSP responses, then the digitalSignature bit SHALL be set.
f. nameConstraints (MAY be present)
This extension SHOULD be marked critical1.
g. extKeyUsage (MAY be present for Cross Certificates; SHALL be present
otherwise)
For Cross Certificates that share a Subject Distinguished Name and Subject
Public Key with a Root CA Certificate operated in accordance with this CP, this
extension MAY be present. If present, this extension SHOULD NOT be marked
critical. This extension SHALL only contain usages for which the Issuing CA has
verified the Cross Certificate is authorized to assert. This extension SHALL NOT
contain the anyExtendedKeyUsage usage.
For all other Subordinate CA Certificates, including Technically Constrained Subordinate CA Certificates, this extension SHALL be present and SHOULD NOT be marked critical2.
For Subordinate CA Certificates that will be used to issue S/MIME Certificates,
the value id-kp-emailProtection SHALL be present. The values
id-kp-serverAuth, id-kp-codeSigning, id-kp-timeStamping, and
anyExtendedKeyUsage SHALL NOT be present. Other values MAY be present.
h. authorityKeyIdentifier (SHALL be present)
This extension SHALL NOT be marked critical. It SHALL contain a keyIdentifier
field and it SHALL NOT contain a authorityCertIssuer or
authorityCertSerialNumber field.
i. subjectKeyIdentifier (SHALL be present)
This extension SHALL NOT be marked critical. It SHALL contain a value that is
included in the keyIdentifier field of the authorityKeyIdentifier extension
in Certificates issued by the Subordinate CA.
a. certificatePolicies (SHALL be present)
This extension SHOULD NOT be marked critical. It SHALL include exactly one of
the reserved policyIdentifiers listed in Section 7.1.6.1, and MAY contain one
or more identifiers documented by the CA in its CP and/or CPS.
If the value of this extension includes a PolicyInformation which contains a
qualifier of type id-qt-cps (OID: 1.3.6.1.5.5.7.2.1), then the value of the
qualifier SHALL be a HTTP or HTTPS URL for the Issuing CA's CPS, Relying Party
Agreement, or other pointer to online policy information provided by the Issuing
CA. If a qualifier of type id-qt-unotice (OID: 1.3.6.1.5.5.7.2.2) is included,
then it SHALL contain explicitText and SHALL NOT contain noticeRef.
b. cRLDistributionPoints (SHALL be present)
This extension SHOULD NOT be marked critical. It SHALL contain at least one
distributionPoint whose fullName value includes a GeneralName of type
uniformResourceIdentifier that includes a URI where the Issuing CA's CRL can
be retrieved.
| Generation | Allowed URI scheme |
|---|---|
| Strict and Multipurpose | Every uniformResourceIdentifier SHALL have the |
| : : URI scheme HTTP. Other schemes SHALL NOT be : | |
| : : present. : | |
| Legacy | At least one uniformResourceIdentifier SHALL |
| : : have the URI scheme HTTP. Other schemes (LDAP,FTP, : | |
| : : ...) MAY be present. : |
c. authorityInformationAccess (SHOULD be present)
This extension SHALL NOT be marked critical.
id-ad-ocsp
The authorityInformationAccess extension MAY contain one or more
accessMethod values of type id-ad-ocsp that specifies the URI of the
Issuing CA's OCSP responder.
| Generation | Allowed URI scheme |
|---|---|
| Strict and Multipurpose | When provided, every accessMethod SHALL have |
| : : the URI scheme HTTP. Other schemes SHALL NOT : | |
| : : be present. : | |
| Legacy | When provided, at least one accessMethod |
| : : SHALL have the URI scheme HTTP. Other schemes : | |
| : : (LDAP, FTP, ...) MAY be present. : |
id-ad-caIssuers
The authorityInformationAccess extension SHOULD contain at least one
accessMethod value of type id-ad-caIssuers that specifies the URI of the
Issuing CA's Certificate.
| Generation | Allowed URI scheme |
|---|---|
| Strict and Multipurpose | When provided, every accessMethod SHALL have |
| : : the URI scheme HTTP. Other schemes SHALL NOT : | |
| : : be present. : | |
| Legacy | When provided, at least one accessMethod |
| : : SHALL have the URI scheme HTTP. Other schemes : | |
| : : (LDAP, FTP, ...) MAY be present. : |
d. basicConstraints (optional)
This extension MAY be present. The cA field SHALL NOT be true.
pathLenConstraint field SHALL NOT be present.
e. keyUsage (SHALL be present)
This extension SHOULD be marked critical.
| Generation | rsaEncryption | idecPublicKey | idEd25519 and idEd448 |
|---|---|---|---|
| Strict | For signing only, bit positions SHALL be set for digitalSignature and MAY be set for nonRepudiation.For key management only, bit positions SHALL be set for keyEncipherment.For dual use, bit positions SHALL be set for digitalSignature and keyEncipherment and MAY be set fornonRepudiation. | For signing only, bit positions SHALL be set for digitalSignature and MAY be set for nonRepudiation.For key management only, bit positions SHALL be set for keyAgreement and MAY be set for encipherOnly or decipherOnly.For dual use, bit positions SHALL be set for digitalSignature and keyAgreement and MAY be set for nonRepudiation and for encipherOnly or decipherOnly (only if keyAgreement is set). | Bit positions SHALL be set for digitalSignature and MAY be set for nonRepudiation. |
| Multipurpose and Legacy | For signing only, bit positions SHALL be set for digitalSignature and MAY be set for nonRepudiation.For key management only, bit positions SHALL be set for keyEncipherment and MAY be set for dataEncipherment.For dual use, bit positions SHALL be set for digitalSignature and keyEncipherment and MAY be set for nonRepudiation and dataEncipherment. | For signing only, bit positions SHALL be set for digitalSignature and MAY be set for nonRepudiation.For key management only, bit positions SHALL be set for keyAgreement and MAY be set for encipherOnly or decipherOnly For dual use, bit positions SHALL be set for digitalSignature and keyAgreement and MAY be set for nonRepudiation and for encipherOnly or decipherOnly (only if keyAgreement is set). | Bit positions SHALL be set for digitalSignature and MAY be set for nonRepudiation. |
Other bit positions SHALL NOT be set.
f. extKeyUsage (SHALL be present)
| Generation | KeyPurposeId |
|---|---|
| Strict | id-kp-emailProtection SHALL be present. Other |
| : : values SHALL NOT be present. : | |
| Multipurpose and Legacy | id-kp-emailProtection SHALL be present. Other |
| : : values MAY be present. : |
The values id-kp-serverAuth, id-kp-codeSigning, id-kp-timeStamping, and
anyExtendedKeyUsage SHALL NOT be present.
g. authorityKeyIdentifier (SHALL be present)
This extension SHALL NOT be marked critical. The keyIdentifier field SHALL be
present. authorityCertIssuer and authorityCertSerialNumber fields SHALL NOT
be present.
h. subjectAlternativeName (SHALL be present)
This extension SHOULD NOT be marked critical unless the subject field is an
empty sequence.
The value of this extension SHALL be encoded as specified in Section 7.1.4.2.1.
i. smimeCapabilities (optional)
This extension MAY be present and SHALL NOT be marked critical. May indicate cryptographic capabilities of the sender of a signed S/MIME message, defined in RFC 4262.
j. subjectDirectoryAttributes (optional)
| Generation | subjectDirectoryAttributes |
|---|---|
| Strict and Multipurpose | Prohibited |
| Legacy | MAY be present and SHALL NOT be marked critical. |
This extension MAY be present. This extension is used to contain verified attributes which are not part of the Subject's Distinguished Name such as dateOfBirth, placeOfBirth, gender, countryOfCitizenship, or countryOfResidence in accordance with RFC 3739 Section 3.2.2.
k. qcStatements (optional)
This extension MAY be present and SHALL NOT be marked critical. Indicates a Certificate that is issued as Qualified within a defined legal framework from an identified country or set of countries in accordance with RFC 3739 Section 3.2.6 and/or ETSI EN 319 412-5, Section 4.
l. Legal Entity Identifier (optional)
| Generation | LEI |
|---|---|
Mailbox-validated | Prohibited |
Organization-validated | LEI (1.3.6.1.4.1.52266.1) MAY be present and |
| : : SHALL NOT be marked critical. Role : | |
| : : (1.3.6.1.4.1.52266.2) SHALL NOT be present. : | |
Sponsor-validated | LEI (1.3.6.1.4.1.52266.1) or for role |
| : : (1.3.6.1.4.1.52266.2) MAY be present and SHALL : | |
| : : NOT be marked critical. : | |
Individual-validated | Prohibited |
The Legal Entity Identifier (LEI) is a 20-character, alpha-numeric code used in accordance with ISO 17442-1:2020, Clause 6 and ISO 17442-2:2020, Clause 4.
The CA SHALL verify that the RegistrationStatus for the LEI record is ISSUED and the EntityStatus is ACTIVE. The CA SHALL only allow use of an LEI if the ValidationSources entry is FULLY_CORROBORATED. An LEI SHALL NOT be used if ValidationSources entry is PARTIALLY_CORROBORATED, PENDING, or ENTITY_SUPPLIED_ONLY.
In cases where the "role" LEI is used, the CA SHALL verify that the LEI data reference is assigned to the Individual Subject whose identity has been verified in accordance with Section 3.2.4.
m. Adobe Extensions (optional)
| Generation | Adobe Extensions |
|---|---|
| Strict | Prohibited |
| Multipurpose and Legacy | MAY be present and SHALL NOT be marked critical. |
| : : May include the Adobe Time-stamp X509 extension : | |
| : : (1.2.840.113583.1.1.9.1) or the Adobe : | |
| : : ArchiveRevInfo extension (1.2.840.113583.1.1.9.2) : |
n. subjectKeyIdentifier (SHOULD be present)
This extension SHALL NOT be marked critical. It SHOULD contain a value that is derived from the Public Key included in the Subscriber Certificate.
All fields and extensions SHALL be set in accordance with
RFC 5280. The CA SHALL NOT
issue a Certificate that contains a keyUsage flag, extKeyUsage value,
Certificate extension, or other data not specified in Section 7.1.2.1, Section
7.1.2.2, or Section 7.1.2.3 unless the CA is aware of a reason for including the
data in the Certificate. If the CA includes fields or extensions in a
Certificate that are not specified but are otherwise permitted by this CP, then
the CA SHALL document the processes and procedures that the CA employs for the
validation of information contained in such fields and extensions in its CP
and/or CPS.
CAs SHALL NOT issue a Certificate with:
extKeyUsage value for a service that is only valid in the context of a privately managed network), unless:The following requirements apply to the subjectPublicKeyInfo field within a
Certificate. 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 SHALL be present, and SHALL 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 SHALL be byte-for-byte
identical with the following hex-encoded bytes: 300d06092a864886f70d0101010500
The CA SHALL indicate an ECDSA key using the id-ecPublicKey (OID:
1.2.840.10045.2.1) algorithm identifier. The parameters SHALL use the
namedCurve encoding.
namedCurve SHALL be secp256r1 (OID:
1.2.840.10045.3.1.7).namedCurve SHALL be secp384r1 (OID: 1.3.132.0.34).namedCurve SHALL be secp521r1 (OID: 1.3.132.0.35).When encoded, the AlgorithmIdentifier for ECDSA keys SHALL be byte-for-byte
identical with the following hex-encoded bytes:
301306072a8648ce3d020106082a8648ce3d030107.301006072a8648ce3d020106052b81040022.301006072a8648ce3d020106052b81040023.The CA SHALL indicate an EdDSA key using one of the following algorithm identifiers below:
algorithm SHALL be id-Ed25519 (OID: 1.3.101.112).algorithm SHALL be id-Ed448 (OID: 1.3.101.113).The parameters for EdDSA keys SHALL be absent.
When encoded, the AlgorithmIdentifier for EdDSA keys SHALL be byte-for-byte
identical with the following hex-encoded bytes:
300506032b6570.300506032b6571.All objects signed by a CA Private Key SHALL conform to this CP 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:
signatureAlgorithm field of a Certificate.signature field of a TBSCertificate (for example, as used by a
Certificate).signatureAlgorithm field of a CertificateListsignature field of a TBSCertListsignatureAlgorithm field of a BasicOCSPResponse.No other encodings are permitted for these fields.
The CA SHALL use one of the following signature algorithms and encodings. When
encoded, the AlgorithmIdentifier SHALL be byte-for-byte identical with the
specified hex-encoded bytes.
RSASSA-PKCS1-v1_5 with SHA-256:
Encoding: 300d06092a864886f70d01010b0500.
RSASSA-PKCS1-v1_5 with SHA-384:
Encoding: 300d06092a864886f70d01010c0500.
RSASSA-PKCS1-v1_5 with SHA-512:
Encoding: 300d06092a864886f70d01010d0500.
RSASSA-PSS with SHA-256, MGF-1 with SHA-256, and a salt length of 32 bytes:
Encoding:
304106092a864886f70d01010a3034a00f300d0609608648016503040201
0500a11c301a06092a864886f70d010108300d0609608648016503040201
0500a203020120
RSASSA-PSS with SHA-384, MGF-1 with SHA-384, and a salt length of 48 bytes:
Encoding:
304106092a864886f70d01010a3034a00f300d0609608648016503040202
0500a11c301a06092a864886f70d010108300d0609608648016503040202
0500a203020130
RSASSA-PSS with SHA-512, MGF-1 with SHA-512, and a salt length of 64 bytes:
Encoding:
304106092a864886f70d01010a3034a00f300d0609608648016503040203
0500a11c301a06092a864886f70d010108300d0609608648016503040203
0500a203020140
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 SHALL use ECDSA with SHA-256. When
encoded, the AlgorithmIdentifier SHALL be byte-for-byte identical with the
following hex-encoded bytes: 300a06082a8648ce3d040302.
If the signing key is P-384, the signature SHALL use ECDSA with SHA-384. When
encoded, the AlgorithmIdentifier SHALL be byte-for-byte identical with the
following hex-encoded bytes: 300a06082a8648ce3d040303.
If the signing key is P-521, the signature SHALL use ECDSA with SHA-512. When
encoded, the AlgorithmIdentifier SHALL be byte-for-byte identical with the
following hex-encoded bytes: 300a06082a8648ce3d040304.
The CA SHALL use the appropriate signature algorithm and encoding based upon the signing key used.
If the signing key is Curve25519, the signature algorithm SHALL be id-Ed25519
(OID: 1.3.101.112). When encoded, the AlgorithmIdentifier SHALL be
byte-for-byte identical with the following hex-encoded bytes: 300506032b6570.
If the signing key is Curve448, the signature algorithm SHALL be id-Ed448 (OID:
1.3.101.113). When encoded, the AlgorithmIdentifier SHALL be byte-for-byte
identical with the following hex-encoded bytes: 300506032b6571.
Attribute values SHALL be encoded according to RFC 5280.
For every valid Certification Path (as defined by RFC 5280, Section 6):
By issuing the Certificate, the CA represents that it followed the procedure set forth in its CPS to verify that, as of the Certificate's issuance date, all of the Subject Information was accurate.
CAs SHALL NOT include a Mailbox Address in a Mailbox Field except as verified in accordance with Section 3.2.2
Subject attributes SHALL 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.
Certificate Field: extensions:subjectAltName
Required/Optional: SHALL be present
Contents: This extension SHALL contain at least one GeneralName entry of
the following types:
Rfc822Name and/orotherName of type id-on-SmtpUTF8Mailbox, encoded in accordance with
RFC 8398All Mailbox Addresses in the subject field or entries of type dirName of
this extension SHALL be repeated as rfc822Name or otherName values of type
id-on-SmtpUTF8Mailbox in this extension.
The CA MAY include GeneralName entries of type dirName provided that the
information contained in the Name complies with the requirements set forth in
the appropriate subsection of Section 7.1.4.2.2 according to the Certificate
Type. Additionally, information contained in the Name SHALL be validated
according to Section 3.1, Section 3.2.3, and/or Section 3.2.4, as appropriate
for the Certificate Type.
For Legacy and Multipurpose Generation profiles, then the CA MAY include
otherName entries of any type, provided that the CA has validated the field
value according to its CPS.
The CA SHALL NOT include GeneralName entries that do not conform to the
requirements of this section.
a. Certificate Field: subject:commonName (OID 2.5.4.3)
Contents: If present, this attribute SHALL contain one of the following
values verified in accordance with Section 3.2.
| Certificate Type | Contents |
|---|---|
Mailbox-validated | Mailbox Address |
Organization-validated | subject:organizationName or Mailbox Address |
Sponsor-validated | Personal Name, Pseudonym, or Mailbox Address |
Individual-validated | Personal Name, Pseudonym, or Mailbox Address |
If present, the Personal Name SHALL contain a name of the Subject. The Personal
Name SHOULD be presented as subject:givenName and/or subject:surname. The
Personal Name MAY be in the Subject's preferred presentation format or a format
preferred by the CA or Enterprise RA, but SHALL be a meaningful representation
of the Subject’s name as verified under Section 3.2.4.
If present, the Mailbox Address SHALL contain a rfc822Name or otherName
value of type id-on-SmtpUTF8Mailbox from extensions:subjectAltName.
If present, the Pseudonym SHALL contain the subject:pseudonym if that Subject
attribute is also present.
Note: Like all other Certificate attributes, subject:commonName and
subject:emailAddress SHALL comply with the attribute upper bounds defined in
RFC 5280.
Additional specifications for naming are provided in Section 3.1.
b. Certificate Field: subject:organizationName (OID 2.5.4.10)
Contents: If present, the subject:organizationName field SHALL contain the
Subject's full legal organization name and/or an Assumed Name as verified under
Section 3.2.3. If both are included, the Assumed Name SHALL appear first,
followed by the full legal organization name in parentheses. 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".
c. Certificate Field: subject:organizationalUnitName (OID: 2.5.4.11)
Contents: If present, the CA SHALL confirm that the
subject:organizationalUnitName is the full legal organization name of an
Affiliate of the subject:organizationName in the Certificate and has been
verified in accordance with the requirements of Section 3.2.3. 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.
d. Certificate Field: subject:organizationIdentifier (2.5.4.97)
Contents: If present, the subject:organizationIdentifier field SHALL
contain a Registration Reference for a Legal Entity assigned in accordance to
the identified Registration Scheme.
The subject:organizationIdentifier SHALL be encoded as a PrintableString or
UTF8String.
The Registration Scheme identified in the Certificate SHALL be the result of the verification performed in accordance with Section 3.2.3. The Registration Scheme SHALL be identified using the following structure in the presented order:
* 3 character Registration Scheme identifier;
* 2 character ISO 3166 country code for the nation in which the Registration Scheme is operated, or if the scheme is operated globally ISO 3166 code "XG" SHALL be used;
* For the NTR Registration Scheme identifier, where registrations are administrated at the subdivision (state or province) level, a plus "+" (0x2B (ASCII), U+002B (UTF-8)) followed by an up-to-three alphanumeric character ISO 3166-2 identifier for the subdivision of the nation in which the Registration Scheme is operated;
* a hyphen-minus "-" (0x2D (ASCII), U+002D (UTF-8));
* Registration Reference allocated in accordance with the identified Registration Scheme.
Registration Schemes listed in Appendix A are recognized as valid under this CP. The CA SHALL:
organizationName field as
specified in Section 7.1.4.2.2; ande. Certificate Field: subject:givenName (2.5.4.42) and/or
subject:surname (2.5.4.4)
Contents: If present, the subject:givenName field and subject:surname
field SHALL contain a Natural Person Subject’s name as verified under Section
3.2.4. Subjects with a single legal name SHALL provide the name in the
subject:surname attribute. The subject:givenName and/or subject:surname
SHALL NOT be present if the subject:pseudonym is present.
f. Certificate Field: subject:pseudonym (2.5.4.65)
Contents: The subject:pseudonym SHALL NOT be present if the
subject:givenName and/or subject:surname are present. If present, the
subject:pseudonym field SHALL be verified according to Section 3.1.3.
g. Certificate Field: subject:serialNumber (2.5.4.5)
Contents: If present, the subject:serialNumber MAY be used to contain an
identifier assigned by the CA or RA to identify and/or to disambiguate the
Subscriber.
In addition, the subject:serialNumber MAY be used in the Sponsor-validated
and Individual-validated profiles to contain a Natural Person Identifier as
described in ETSI EN 319 412-1 Section 5.1.3. Registration Schemes listed in
Appendix A are recognized as valid under this CP. The CA SHALL confirm that the
Individual represented by the Natural Person Identifier is the same as the
Certificate Subject in accordance with Section 3.2.4.
h. Certificate Field: subject:emailAddress (1.2.840.113549.1.9.1)
Contents: If present, the subject:emailAddress SHALL contain a single
Mailbox Address as verified under Section 3.2.2.
i. Certificate Field: subject:title (2.5.4.12) Contents: If present,
the subject:title field SHALL contain only a organizational role/title or a
regulated professional designation verified according to Section 3.2.4.
j. Certificate Field: Number and street: subject:streetAddress (OID:
2.5.4.9)
Contents: If present, the subject:streetAddress field SHALL contain the
Subject's street address information as verified under Section 3.2.3 for
Organization-validated and Sponsor-validated Certificate Types or Section 3.2.4
for Individual-validated Certificate Types.
k. Certificate Field: subject:localityName (OID: 2.5.4.7)
Contents: If present, the subject:localityName field SHALL contain the
Subject's locality information as verified under Section 3.2.3 for
Organization-validated and Sponsor-validated Certificate Types or Section 3.2.4
for Individual-validated Certificate Types. If the subject:countryName field
specifies the ISO 3166-1 user-assigned code of XX in accordance with Section
7.1.4.2.2 (n), the localityName field MAY contain the Subject's locality
and/or state or province information.
l. Certificate Field: subject:stateOrProvinceName (OID: 2.5.4.8)
Contents: If present, the subject:stateOrProvinceName field SHALL contain
the Subject's state or province information as verified under Section 3.2.3 for
Organization-validated and Sponsor-validated Certificate Types or Section 3.2.4
for Individual-validated Certificate Types. If the subject:countryName field
specifies the ISO 3166-1 user-assigned code of XX in accordance with Section
7.1.4.2.2 (n), the subject:stateOrProvinceName field MAY contain the full name
of the Subject's country information.
m. Certificate Field: subject:postalCode (OID: 2.5.4.17)
Contents: If present, the subject:postalCode field SHALL contain the
Subject's zip or postal information as verified under Section 3.2.3 for
Organization-validated and Sponsor-validated Certificate Types or Section 3.2.4
for Individual-validated Certificate Types.
n. Certificate Field: subject:countryName (OID: 2.5.4.6)
Contents: If present, the subject:countryName SHALL contain the two-letter
ISO 3166-1 country code associated with the location of the Subject verified
under Section 3.2.3 for Organization-validated and Sponsor-validated Certificate
Types or Section 3.2.4 for Individual-validated Certificate Types. If a Country
is not represented by an official ISO 3166-1 country code, the CA MAY specify
the ISO 3166-1 user-assigned code of XX indicating that an official ISO 3166-1
alpha-2 code has not been assigned.
| Attribute | Legacy | Multipurpose | Strict |
|---|---|---|---|
commonName | MAY | MAY | MAY |
organizationName | SHALL NOT | SHALL NOT | SHALL NOT |
organizationalUnitName | SHALL NOT | SHALL NOT | SHALL NOT |
organizationIdentifier | SHALL NOT | SHALL NOT | SHALL NOT |
givenName | SHALL NOT | SHALL NOT | SHALL NOT |
surname | SHALL NOT | SHALL NOT | SHALL NOT |
pseudonym | SHALL NOT | SHALL NOT | SHALL NOT |
serialNumber | MAY | MAY | MAY |
emailAddress | MAY | MAY | MAY |
title | SHALL NOT | SHALL NOT | SHALL NOT |
streetAddress | SHALL NOT | SHALL NOT | SHALL NOT |
localityName | SHALL NOT | SHALL NOT | SHALL NOT |
stateOrProvinceName | SHALL NOT | SHALL NOT | SHALL NOT |
postalCode | SHALL NOT | SHALL NOT | SHALL NOT |
countryName | SHALL NOT | SHALL NOT | SHALL NOT |
| Other | SHALL NOT | SHALL NOT | SHALL NOT |
| Attribute | Legacy | Multipurpose | Strict |
|---|---|---|---|
commonName | MAY | MAY | MAY |
organizationName | SHALL | SHALL | SHALL |
organizationalUnitName | MAY | MAY | MAY |
organizationIdentifier | SHALL | SHALL | SHALL |
givenName | SHALL NOT | SHALL NOT | SHALL NOT |
surname | SHALL NOT | SHALL NOT | SHALL NOT |
pseudonym | SHALL NOT | SHALL NOT | SHALL NOT |
serialNumber | MAY | MAY | MAY |
emailAddress | MAY | MAY | MAY |
title | SHALL NOT | SHALL NOT | SHALL NOT |
streetAddress | MAY | MAY | SHALL NOT |
localityName | MAY | MAY | MAY |
stateOrProvinceName | MAY | MAY | MAY |
postalCode | MAY | MAY | SHALL NOT |
countryName | MAY | MAY | MAY |
| Other | MAY | SHALL NOT | SHALL NOT |
| Attribute | Legacy
| Multipurpose
| Strict
(See |
: : (See Note 1) : (See Note 2) : Note 2) :
| ------------------------ | ------------ | ---------------- | --------------- |
| commonName | MAY | MAY | MAY |
| organizationName | SHALL | SHALL | SHALL |
| organizationalUnitName | MAY | MAY | MAY |
| organizationIdentifier | SHALL | SHALL | SHALL |
| givenName | MAY | MAY | MAY |
| surname | MAY | MAY | MAY |
| pseudonym | MAY | MAY | MAY |
| serialNumber | MAY | MAY | MAY |
| emailAddress | MAY | MAY | MAY |
| title | MAY | MAY | MAY |
| streetAddress | MAY | MAY | SHALL NOT |
| localityName | MAY | MAY | MAY |
| stateOrProvinceName | MAY | MAY | MAY |
| postalCode | MAY | MAY | SHALL NOT |
| countryName | MAY | MAY | MAY |
| Other | MAY | SHALL NOT | SHALL NOT |
Note: 1. Legacy Generation profiles MAY omit the subject:givenName,
subject:surname, and subject:pseudonym attributes and include only the
subject:commonName as described in Section 7.1.4.2.2 (a). 2. Multipurpose and
Strict Generation profiles SHALL include either subject:givenName and/or
subject:surname, or the subject:pseudonym.
| Attribute | Legacy
| Multipurpose
| Strict
(See |
: : (See Note 1) : (See Note 2) : Note 2) :
| ------------------------ | ------------ | ---------------- | --------------- |
| commonName | MAY | MAY | MAY |
| organizationName | SHALL NOT | SHALL NOT | SHALL NOT |
| organizationalUnitName | SHALL NOT | SHALL NOT | SHALL NOT |
| organizationIdentifier | SHALL NOT | SHALL NOT | SHALL NOT |
| givenName | MAY | MAY | MAY |
| surname | MAY | MAY | MAY |
| pseudonym | MAY | MAY | MAY |
| serialNumber | MAY | MAY | MAY |
| emailAddress | MAY | MAY | MAY |
| title | MAY | MAY | MAY |
| streetAddress | MAY | MAY | SHALL NOT |
| localityName | MAY | MAY | MAY |
| stateOrProvinceName | MAY | MAY | MAY |
| postalCode | MAY | MAY | SHALL NOT |
| countryName | MAY | MAY | MAY |
| Other | MAY | SHALL NOT | SHALL NOT |
Note:
subject:givenName,
subject:surname, and subject:pseudonym attributes and include only the
subject:commonName as described in Section 7.1.4.2.2 (a).subject:givenName and/or subject:surname, or the subject:pseudonym.By issuing a Subordinate CA Certificate, the CA represents that it followed the procedure set forth in its CPS to verify that, as of the Certificate's issuance date, all of the Subject Information was accurate.
a. Certificate Field: subject:commonName (OID 2.5.4.3)
Required/Optional: SHALL be present
Contents: This field SHOULD contain an identifier for the Certificate such
that the Certificate's Name is unique across all Certificates issued by the
Issuing CA.
b. Certificate Field: subject:organizationName (OID 2.5.4.10)
Required/Optional: SHALL be present
Contents: This field SHALL contain either the Subject CA's name or DBA as
verified under Section 3.2.3.2.2 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".
c. Certificate Field: subject:countryName (OID: 2.5.4.6)
Required/Optional: SHALL be present
Contents: This field SHALL contain the two‐letter ISO 3166‐1 country code
for the country in which the CA's place of business is located.
d. Other Subject Attributes
Other attributes MAY be present within the subject field. If present, other
attributes SHALL contain information that has been verified by the CA.
For a Subordinate CA Certificate to be considered Technically Constrained, the
Certificate SHALL include an Extended Key Usage (EKU) extension specifying all
extended key usages for which the Subordinate CA Certificate is authorized to
issue Certificates. The anyExtendedKeyUsage KeyPurposeId SHALL NOT appear
within this extension.
If the Subordinate CA Certificate includes the id-kp-emailProtection extended
key usage, then for the Subordinate CA Certificate to be considered Technically
Constrained it SHALL include the nameConstraints X.509v3 extension with
constraints on rfc822Name and directoryName as follows:
For each rfc822Name in permittedSubtrees, each rfc822Name SHALL
contain either a FQDN or a U+002E FULL STOP (".") character followed by a
FQDN. The rfc822Name SHALL NOT contain an email address. The CA SHALL
confirm that the Applicant has registered the FQDN contained in the
rfc822Name or has been authorized by the domain registrant to act on the
registrant's behalf in line with the verification practices of Section
3.2.2.3.
For each directoryName in permittedSubtrees, the CA SHALL confirm the
Applicant's and/or Subsidiary's Organizational name and location such that
end entity Certificates issued from the Subordinate CA Certificate will be
in compliance with Section 7.1.2.4.
This section describes the content requirements for the Root CA, Subordinate CA, and Subscriber Certificates as they relate to the identification of Certificate Policy.
The following CA/Browser Forum Certificate Policy identifiers are reserved for use by CAs to assert that a Certificate complies with this CP.
| Certificate Type | Generation | Policy Identifier |
|---|---|---|
Mailbox-validated | Legacy | 2.23.140.1.5.1.1 |
Mailbox-validated | Multipurpose | 2.23.140.1.5.1.2 |
Mailbox-validated | Strict | 2.23.140.1.5.1.3 |
Organization-validated | Legacy | 2.23.140.1.5.2.1 |
Organization-validated | Multipurpose | 2.23.140.1.5.2.2 |
Organization-validated | Strict | 2.23.140.1.5.2.3 |
Sponsor-validated | Legacy | 2.23.140.1.5.3.1 |
Sponsor-validated | Multipurpose | 2.23.140.1.5.3.2 |
Sponsor-validated | Strict | 2.23.140.1.5.3.3 |
Individual-validated | Legacy | 2.23.140.1.5.4.1 |
Individual-validated | Multipurpose | 2.23.140.1.5.4.2 |
Individual-validated | Strict | 2.23.140.1.5.4.3 |
A Root CA Certificate SHOULD NOT contain the certificatePolicies extension. If
present, the extension SHALL conform to the requirements set forth for
Certificates issued to Subordinate CAs in Section 7.1.6.3.
A Certificate issued to a Subordinate CA that is not an Affiliate of the Issuing CA:
anyPolicy identifier (2.5.29.32.0).A Certificate issued to a Subordinate CA that is an Affiliate of the Issuing CA SHALL include a set of policy identifiers from one of the two options below:
anyPolicy identifier (2.5.29.32.0).The Subordinate CA and the Issuing CA SHALL represent, in their CP and/or CPS, that all Certificates containing a policy identifier indicating compliance with the Baseline Requirements are issued and managed in accordance with this CP.
A Certificate issued to a Subscriber SHALL contain, within the Certificate's
certificatePolicies extension, a policy identifier that is specified in
Section 7.1.6.1.
The Certificate MAY also contain additional policy identifier(s) defined by the Issuing CA. The Issuing CA SHALL document in its CP and/or CPS that the Certificates it issues containing the specified policy identifier(s) are managed in accordance with the Baseline Requirements.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
If present, the reasonCode (OID 2.5.29.21) extension SHALL NOT be marked
critical.
If a CRL entry is for a Root CA or Subordinate CA Certificate, including Cross
Certificates, this CRL entry extension SHALL be present. The CRLreason of
certificateHold (6) SHALL NOT be used for Root CA or Subordinate CA
Certificates.
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 SHALL NOT be unspecified (0). If the reason for
revocation is unspecified, CAs SHALL omit the reasonCode entry extension.
The Repository MAY include CRL entries that have a CRLreason of
certificateHold (6) for Certificates that include the Certificate Policy
identifiers for the Legacy or Multipurpose Generations. The Repository SHALL NOT
include CRL entries that have a CRLreason of certificateHold (6) for
Certificates that include the Certificate Policy identifiers for the Strict
Generation.
If a reasonCode CRL entry extension is present, the CRLReason SHALL indicate
the most appropriate reason for revocation of the Certificate, as defined by the
CA within its CP and/or CPS.
If an OCSP response is for a Root CA or Subordinate CA Certificate, including
Cross Certificates, and that Certificate has been revoked, then the
revocationReason field within the RevokedInfo of the CertStatus SHALL be
present.
The CRLReason indicated SHALL contain a value permitted for CRLs, as specified
in Section 7.2.2.
No stipulation.
The singleExtensions of an OCSP response SHALL 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 SHALL
either be Technically Constrained in line with Section 7.1.5 and audited in line
with Section 8.8 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 SHALL 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:
No stipulation.
The CA SHALL undergo an audit in accordance with one of the following schemes:
The audit SHALL be conducted by a Qualified Auditor, as specified in Section 8.2.
For Delegated Third Parties that are not Enterprise RAs, then the CA SHALL obtain an audit report, issued under the auditing standards that underlie the accepted audit schemes found above in this 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 CPS as described in Section 1.3.2. 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).
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 SHALL 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 SHALL contain at least the following clearly-labelled information:
An authoritative English language version of the publicly available audit information SHALL be provided by the Qualified Auditor and the CA SHALL ensure that it is publicly available.
The Audit Report SHALL be available as a PDF, and SHALL be text searchable for all information required. Each SHA-256 fingerprint within the Audit Report SHALL be uppercase letters and SHALL NOT contain colons, spaces, or line feeds. See https://www.ccadb.org/policy#51-audit-statement-content for more information.
During the period in which the CA issues Certificates, the CA SHALL monitor adherence to its CPS and the Baseline Requirements and control its service quality by performing self audits on at least a quarterly basis against a randomly selected sample including a minimum of the greater of thirty (30) Certificates or three percent (3%) of the Certificates issued by it during the period commencing immediately after the previous self-audit sample was taken.
Except for Delegated Third Parties, Enterprise RAs, and Technically Constrained Subordinate CAs that undergo an annual audit that meets the criteria specified in Section 8.4, the CA SHALL ensure the practices and procedures of delegated parties are in compliance with the Baseline Requirements and the relevant CPS. The CA shall document the obligations of delegated parties and perform monitoring on at least an annual basis of the delegated parties' adherence with those obligations.
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 publish a Privacy Policy that provides information on the CA's data protection practices. The Privacy Policy SHOULD include information on how the CA collects, uses, shares, store, and deletes or retains data, as well as contact information for the exercise of privacy rights. The CA SHALL document where to obtain this information within Section 9.4.1 of the CA's CPS.
The CA or RA SHALL treat all personal information about an Individual that is not publicly available in the contents of a Certificate as private information. This includes information that links a Pseudonym to the real identity of the Subject Individual.
No stipulation.
The CA or RA SHALL protect private information using appropriate safeguards and a reasonable degree of care. The CA or RA SHALL require the same from any service providers who handle private information on behalf of the CA or RA.
The CA or RA shall provide appropriate notices to, and receive the necessary consent, from Subject Individuals before using private information for any purpose other than providing services related to the issuance and management of Certificates. The CA or RA shall require the same from any service providers who handle private information on behalf of the CA or RA.
No stipulation.
No stipulation.
No stipulation.
By issuing a Certificate, the CA makes the 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 the Baseline Requirements and its CPS in issuing and managing the Certificate.
The Certificate Warranties specifically include, but are not limited to, the following:
subject field and subjectAltName extension (or was delegated such right or control by someone who had such right to use or control);
ii. followed the procedure when issuing the Certificate; and
iii. accurately described the procedure in the CA's CPS;The Root CA SHALL be responsible for the performance and warranties, compliance with this CP, and for all liabilities and indemnification obligations of the Subordinate CA under this CP, as if the Root CA were the Subordinate CA issuing the Certificates.
No stipulation.
The CA SHALL require, as part of the Subscriber Agreement or Terms of Use, 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 Applicant's:
The CA SHALL implement a process to ensure that each Subscriber Agreement or Terms of Use is legally enforceable against the Applicant. In either case, the Agreement SHALL 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 Agreement or Terms of Use.
The Subscriber Agreement or Terms of Use SHALL 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 this CP, as if the tasks had not been delegated.
If the CA has issued and managed the Certificate in compliance with the Baseline Requirements and its CPS, 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 CPS. If the CA has not issued or managed the Certificate in compliance with the Baseline Requirements and its CPS, 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 limit its liability for Certificates that are not issued or managed in compliance with the Baseline Requirements or its CPS, then the CA SHALL include the limitations on liability in the CA's CPS.
Notwithstanding any limitations on its liability to Subscribers and Relying Parties, the CA understands and acknowledges that the Application Software Suppliers who have agreed to distribute the Root CA Certificate do not assume any obligation or potential liability of the CA under this CP or that otherwise might exist because of the issuance or maintenance of Certificates or reliance thereon by Relying Parties or others. Thus, except in the case where the CA is a government entity, the CA SHALL defend, indemnify, and hold harmless each Application Software Supplier for any and all claims, damages, and losses suffered by such Application Software Supplier related to a Certificate issued by the CA, regardless of the cause of action or legal theory involved. This does not apply, however, to any claim, damages, or loss suffered by such Application Software Supplier related to a Certificate issued by the CA where such claim, damage, or loss was directly caused by such Application Software Supplier's software displaying as not trustworthy a Certificate that is still valid, or displaying as trustworthy: (1) a Certificate that has expired, or (2) a Certificate that has been revoked (but only in cases where the revocation status is currently available from the CA online, and the application software either failed to check such status or ignored an indication of revoked status).
No stipulation.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
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 this CP under this section, and the specific modification to this CP implemented by the CA.
The CA SHALL 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 public@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 the Baseline Requirements accordingly.
Any modification to CA practice enabled under this section SHALL be discontinued if and when the Law no longer applies, or this CP is modified to make it possible to comply with both them and the Law simultaneously. An appropriate change in practice, modification to the CA’s CPS and a notice to the CA/Browser Forum, as outlined above, SHALL be made within 90 days.
No stipulation.
No stipulation.
No stipulation.
The following Registration Schemes are recognized as valid under this CP for use
in the subject:organizationIdentifier attribute described in Section
7.1.4.2.2.
The country code used in the Registration Scheme identifier SHALL match that of
the subject:countryName in the Certificate as specified in Section 7.1.4.2.2.
NTR: For an identifier allocated by a national or state trade register
to the Legal Entity named in the subject:organizationName.
VAT: For an identifier allocated by the national tax authorities to the
Legal Entity named in the subject:organizationName.
PSD: For a national authorization number allocated to the payment
service provider named in the subject:organizationName under Payments
Services Directive (EU) 2015/2366. This shall use the extended structure as
defined in ETSI TS 119 495, clause 5.2.1.
LEI: For a Legal Entity Identifier as specified in ISO 17442 for the
entity named in the subject:organizationName. The 2 character ISO 3166
country code SHALL be set to 'XG'.
The following Registration Schemes are recognized as valid for use in the
subject:serialNumber attribute described in Section 7.1.4.2.2.
PAS: For an identifier based on a passport number issued to the Subject Individual.
IDC: For an identifier based on a national identity card issued to the Subject Individual.
PNO: For an identifier based on a national personal number (or national civic registration number) issued to the Subject Individual.
TIN: For an identifier based on Tax Identification Number issued to the Subject Individual.
Following the Effective Date for this CP an Extant S/MIME CA MAY continue to issue end entity Certificates that are compliant with this CP.
On or after September 15, 2024, all newly-issued Publicly-Trusted end entity Certificates SHALL be issued from S/MIME Subordinate CAs that are compliant with this CP.
For backwards compatibility, Extant S/MIME CA Certificates that share the same Public Keys with S/MIME Subordinate CAs that are compliant with this CP, or are no longer used for signing end entity Certificates, are not required to be revoked.
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 issues, 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:
Application Software Supplier: A supplier of email client software or other relying-party application software such as mail user agents (web-based or application based) and email service providers that process S/MIME Certificates.
Assumed Name: Also known as "doing business as", "DBA", or "d/b/a" name in the US and "trading as" name in the UK.
Attestation: 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 this CP.
CAA: From RFC 8659: "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.
Certification Authority (or CA): 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.
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 (or CP): A set of rules that indicates the applicability of a named Certificate to a particular community and/or PKI implementation with common security requirements.
Certification Practice Statement (or CPS): One of several documents forming the governance framework in which Certificates are created, issued, managed, and used.
Certificate Problem Report: Complaint of suspected Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, or inappropriate conduct related to Certificates.
Certificate Profile: A set of documents or files that defines requirements for Certificate content and Certificate extensions in accordance with Section 7 e.g., a section in a CA’s CPS or a Certificate template file used by CA software.
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.
Certificate Type: The S/MIME Baseline Requirements define Certificate Profiles differentiated by the type of Subject, (for example Mailbox, Organization, Sponsored, Individual).
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%.
Conversion: The process of converting text from one writing system to ASCII characters.
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 Certificate: A Certificate that is used to establish a trust relationship between two Root CAs.
CSPRNG: A pseudo-random number generator intended for use in a cryptographic system.
Delegated Third Party: A Natural Person or Legal Entity that is not the CA but is authorized by the CA, and whose activities are not within the scope of the appropriate CA audits, to assist in the Certificate Management Process by performing or fulfilling one or more of the CA requirements found herein.
Digital Identity Document: a government-issued identity document that is issued in a machine-processable form, that is digitally signed by the issuer, and that is in purely digital form.
Domain Label: From RFC 8499: "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.
Electronic Identification (eID): A credential containing Individual identification data and/or attributes and which is used for authentication for an online service.
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.
Extant S/MIME CA: A Subordinate CA that:
notBefore field is
before September 1, 2023 and has issued end entity S/MIME Certificates;anyExtendedKeyUsage in the EKU extension, or contains
id-kp-emailProtection in the EKU extension;nameConstraints extension
that is not marked critical; b. The CA Certificate contains a policy
qualifier of type UserNotice which contains explicitText that uses an
encoding that is not permitted by
RFC 5280 (i.e., the DisplayText is
encoded using BMPString or VisibleString); andanyPolicy identifier (2.5.29.32.0) or
specific OIDs in the certificatePolicies extension that do not include
those defined in Section 7.1.6.1 of this CP.Fully-Qualified Domain Name: A Domain Name that includes the Domain Labels of all superior nodes in the Internet Domain Name System.
Generation: The S/MIME Baseline Requirements define several Generations of Certificate Profile for each Certificate Type.
Google: Google Trust Services Europe Ltd for Subscribers in the EU and Google Trust Services LLC (a Delaware corporation) for all other Subscribers.
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.).
Individual: A Natural Person.
Individual-Validated: Refers to a Certificate Subject that includes only Individual (Natural Person) attributes, rather than attributes linked to an Organization.
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.
Jurisdiction of Incorporation: The country and (where applicable) the state or province or locality where the organization's legal existence was established by a filing with (or an act of) an appropriate government agency or entity (e.g., where it was incorporated). In the context of a Government Entity, the country and (where applicable) the state or province where the Entity's legal existence was created by law.
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.
Legacy Profile: The S/MIME Legacy Generation profiles provide flexibility
for existing reasonable S/MIME Certificate practices to become auditable under
the S/MIME Baseline Requirements. This includes options for Subject DN
attributes, extKeyUsage, and other extensions. The Legacy Profiles will be
deprecated in a future version of the S/MIME Baseline Requirements.
Legal Entity: An association, corporation, partnership, proprietorship, trust, government entity or other entity with legal standing in a country's legal system.
Mailbox-Validated (MV): Refers to a Certificate Subject that is limited to
(optional) subject:emailAddress and/or subject:serialNumber attributes.
Mailbox Address: Also Email Address. The format of a Mailbox Address is defined as a "Mailbox" as specified in Section 4.1.2 of RFC 5321 and amended by Section 3.2 of RFC 6532, with no additional padding or structure.
Mailbox Field: In Subscriber Certificates contains a Mailbox Address of the
Subject via rfc822Name or otherName value of type id-on-SmtpUTF8Mailbox in
the subjectAltName extension, or in Subordinate CA Certificates via
rfc822Name in permittedSubtrees within the nameConstraints extension.
Multipurpose Profile: The S/MIME Multipurpose Generation profiles are
aligned with the more defined Strict Profiles, but with additional options for
extKeyUsage and other extensions. This is intended to allow flexibility for
crossover use cases between document signing and secure email.
Natural Person: An Individual; a human being as distinguished from a Legal Entity.
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.
Organization-Validated: Refers to a Certificate Subject that includes only Organizational (Legal Entity) attributes, rather than attributes linked to an Individual.
Parent Company: A company that Controls a Subsidiary Company.
Personal Name: Personal Name is a name of an Individual Subject typically
presented as subject:givenName and/or subject:surname. However, the Personal
Name may be in a format preferred by the Subject, the CA, or Enterprise RA as
long as it remains a meaningful representation of the Subject’s verified name.
Physical Identity Document: a government-issued identity document issued in physical and human-readable form (such as a passport or national identity card).
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.
Pseudonym: A fictitious identity that a person assumes for a particular purpose. Unlike an anonymous identity, a pseudonym can be linked to the person's real identity.
Public Key: The key of a Key Pair that can 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 CA 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.
Requirements: The S/MIME Baseline Requirements found in CA/B Forum's website.
Root CA: The top level Certification Authority whose Root CA Certificate is distributed by Application Software Suppliers and that issues Subordinate CA Certificates.
Root CA 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.
Sponsor-validated: Refers to a Certificate Subject which combines Individual
(Natural Person) attributes in conjunction with an subject:organizationName
(an associated Legal Entity) attribute. Registration for Sponsor-validated
Certificates MAY be performed by an Enterprise RA where the
subject:organizationName is either that of the delegated enterprise, or an
Affiliate of the delegated enterprise, or that the delegated enterprise is an
agent of the named Subject Organization.
Strict Profile: The S/MIME Strict Generation profiles are the long term
target profile for S/MIME Certificates with extKeyUsage limited to
id-kp-emailProtection, and stricter use of Subject DN attributes and other
extensions.
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 mailbox under the control and operation of the Subscriber.
Subject Identity Information: Information that identifies the Certificate
Subject. Subject Identity Information does not include a Mailbox Address listed
in the subject:commonName or subject:emailAddress fields, or in the
subjectAltName extension.
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.
Supplementary Evidence: Used in addition to authoritative evidence to strengthen the reliability of the identity verification and/or as evidence for attributes that are not evidenced by the authoritative evidence.
Technically Constrained Subordinate CA Certificate: A Subordinate CA Certificate which uses a combination of Extended Key Usage settings and Name Constraint settings to limit the scope within which the Subordinate CA Certificate MAY issue Certificates to Subscriber or additional Subordinate CAs.
Terms of Use: Provisions regarding the safekeeping and acceptable uses of a Certificate issued in accordance with this CP when the Applicant/Subscriber is an Affiliate of the CA or is the CA.
Valid Certificate: A Certificate that passes the validation procedure specified in RFC 5280.
Validation Specialist: Someone who performs the information verification duties specified by this CP.
Validity Period: From RFC 5280: "The period of time from notBefore through notAfter, inclusive."
| Acronym | Meaning |
|---|---|
| CA | Certification Authority |
| CAA | Certification Authority Authorization |
| CP | Certificate Policy |
| CPS | Certification Practice Statement |
| CRL | Certificate Revocation List |
| DBA | Doing Business As |
| DNS | Domain Name System |
| ETSI | European Telecommunications Standards Institute |
| FIPS | (US Government) Federal Information Processing Standard |
| ICAO | International Civil Aviation Organization |
| ISO | International Organization for Standardization |
| MV | Mailbox-validated |
| 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) |
| TLS | Transport Layer Security |
ETSI EN 319 403, Electronic Signatures and Infrastructures (ESI); Trust Service Provider Conformity Assessment - Requirements for conformity assessment bodies assessing Trust Service Providers.
ETSI EN 319 403-1, Electronic Signatures and Infrastructures (ESI); Trust Service Provider Conformity Assessment; Part 1 - Requirements for conformity assessment bodies assessing Trust Service Providers.
ETSI EN 319 411-1, Electronic Signatures and Infrastructures (ESI); Policy and security requirements for Trust Service Providers issuing Certificates; Part 1: General requirements.
ETSI EN 319 411-2, Electronic Signatures and Infrastructures (ESI); Policy and security requirements for Trust Service Providers issuing Certificates; Part 2: Requirements for trust service providers issuing EU qualified Certificates.
ETSI EN 319 412-1, Electronic Signatures and Infrastructures (ESI); Certificate Profiles; Part 1: Overview and common data structures.
ETSI EN 319 412-5, Electronic Signatures and Infrastructures (ESI); Certificate Profiles; Part 5: QCStatements.
ETSI TS 119 495, Electronic Signatures and Infrastructures (ESI); Sector Specific Requirements; Certificate Profiles and TSP Policy Requirements for Open Banking.
ETSI TS 119 172-4, Electronic Signatures and Infrastructures (ESI); Signature Policies;. Part 4: Signature applicability rules.
FIPS 140-2, Federal Information Processing Standards Publication - Security Requirements For Cryptographic Modules, Information Technology Laboratory, National Institute of Standards and Technology, May 25, 2001.
ICAO DOC 9303, Machine Readable Travel Documents, Part 10, Logical Data Structure (LDS) for Storage of Biometrics and Other Data in the Contactless Integrated Circuit (IC), International Civil Aviation Organization, Eighth Edition, 2021.
ICAO DOC 9303, Machine Readable Travel Documents, Part 11, Security Mechanisms for MRTDs, International Civil Aviation Organization, Eighth Edition, 2021.
ISO 17065:2012, Conformity assessment — Requirements for bodies certifying products, processes and services.
ISO 17442-1:2020, Financial services — Legal entity identifier (LEI) - Part 1: Assignment.
ISO 17442-2:2020, Financial services — Legal entity identifier (LEI) - Part 2: Application in digital Certificates.
Network and Certificate System Security Requirements, Version 1.7 or later. See https://cabforum.org/network-security-requirements/.
NIST SP 800-89, Recommendation for Obtaining Assurances for Digital Signature Applications.
RFC 2119, Request for Comments: 2119, Key words for use in RFCs to Indicate Requirement Levels, S. Bradner. March 1997.
RFC 3647, Request for Comments: 3647, Internet X.509 Public Key Infrastructure: Certificate Policy and Certification Practices Framework, S. Chokhani, et al. November 2003.
RFC 3739, Request for Comments: 3739, Internet X.509 Public Key Infrastructure: Qualified Certificates Profile, S. Santesson, et al. March 2004.
RFC 4262, Request for Comments: 4262, X.509 Certificate Extension for Secure/Multipurpose Internet Mail Extensions (S/MIME) Capabilities, S. Santesson. December 2005.
RFC 5019, Request for Comments: 5019, The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments, A. Deacon, et al. September 2007.
RFC 5280, Request for Comments: 5280, Internet X.509 Public Key Infrastructure: Certificate and Certificate Revocation List (CRL) Profile, Cooper et al. May 2008.
RFC 6818, Updates to the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. January 2013.
RFC 6960, Request for Comments: 6960, X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP. S. Santesson, et al. June 2013.
RFC 8398, Request for Comments: 8398, Internationalized Email Addresses in X.509 Certificates, MAY 2018. A. Melnikov, et al. May 2018.
RFC 8499, Request for Comments: 8499, DNS Terminology. P. Hoffman, et al. January 2019.
RFC 8659, Request for Comments: 8659, DNS Certification Authority Authorization (CAA) Resource Record, Hallam-Baker, et al. November 2019.
"TLS Baseline Requirements" means the relevant version of the CA/Browser Forum's "Baseline Requirements for the Issuance and Management of Publicly‐Trusted TLS Server Certificates". See https://cabforum.org/baseline-requirements-documents/
WebTrust for Certification Authorities, CPA Canada.
X.509, Recommendation ITU-T X.509 (10/2012) | ISO/IEC 9594-8:2014 (E), Information technology – Open Systems Interconnection – The Directory: Public-key and attribute Certificate frameworks.
| Version | Date | Change owner | Note |
|---|---|---|---|
| 1.0 | 2023-08-31 | CA Policy Authority | Initial publication |
| 2.0 | 2023-10-11 | CA Policy Authority | Add Google Trust Services Europe Ltd |
Non-critical Name Constraints are an exception to
RFC 5280 (4.2.1.10),
however, they MAY be used until the nameConstraints extension is
supported by Application Software Suppliers whose software is used by a
substantial portion of Relying Parties worldwide. ↩
While RFC 5280, Section 4.2.1.12, notes that this extension will generally only appear within end-entity Certificates, this CP makes use of this extension to further protect relying parties by limiting the scope of Subordinate Certificates, as implemented by a number of Application Software Suppliers. ↩