Amazon Web Services Certificate Policy. Version 1.0.1

(1)

Amazon Web Services

Certificate Policy

(2)

4.9.7.1 For the status of Subscriber Certificates 4.9.7.2 For the status of Subordinate CA Certificates 4.9.8 Maximum latency for CRLs (if applicable) 4.9.9 On-line revocation/status checking availability 4.9.10 On-line revocation checking requirements 4.9.10.1 For the status of Subscriber Certificates 4.9.10.2 For the status of Subordinate CA Certificates 4.9.11 Other forms of revocation advertisements available

(5)

4.9.12 Special requirements re key compromise 4.9.13 Circumstances for suspension

4.9.14 Who can request suspension 4.9.15 Procedure for suspension request 4.9.16 Limits on suspension period 4.10 Certificate status services 4.10.1 Operational characteristics 4.10.2 Service availability

4.10.3 Optional features 4.11 End of subscription 4.12 Key escrow and recovery

4.12.1 Key escrow and recovery policy and practices

4.12.2 Session key encapsulation and recovery policy and practices 5 FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS 5.1 Physical controls

5.1.1 Site location and construction 5.1.2 Physical access

5.1.3 Power and air conditioning 5.1.4 Water exposures

5.1.5 Fire prevention and protection 5.1.6 Media storage

5.1.7 Waste disposal 5.1.8 Off-site backup 5.2 Procedural controls 5.2.1 Trusted roles

5.2.2 Number of persons required per task

5.2.3 Identification and authentication for each role 5.2.4 Roles requiring separation of duties

5.3 Personnel controls

5.3.1 Qualifications, experience, and clearance requirements 5.3.2 Background check procedures

5.3.3 Training requirements

5.3.4 Retraining frequency and requirements 5.3.5 Job rotation frequency and sequence 5.3.6 Sanctions for unauthorized actions 5.3.7 Independent contractor requirements 5.3.8 Documentation supplied to personnel 5.4 Audit logging procedures

5.4.1 Types of events recorded 5.4.2 Frequency of processing log 5.4.3 Retention period for audit log 5.4.4 Protection of audit log 5.4.5 Audit log backup procedures

5.4.6 Audit collection system (internal vs. external) 5.4.7 Notification to event-causing subject

(6)

5.5 Records archival

5.5.1 Types of records archived 5.5.2 Retention period for archive 5.5.3 Protection of archive 5.5.4 Archive backup procedures

5.5.5 Requirements for time-stamping of records 5.5.6 Archive collection system (internal or external) 5.5.7 Procedures to obtain and verify archive information 5.6 Key changeover

5.7 Compromise and disaster recovery

5.7.1 Incident and compromise handling procedures

5.7.2 Computing resources, software, and/or data are corrupted 5.7.3 Entity private key compromise procedures

5.7.4 Business continuity capabilities after a disaster 5.8 CA or RA termination

6 TECHNICAL SECURITY CONTROLS 6.1 Key pair generation and installation 6.1.1 Key pair generation

6.1.1.1 CA Key Pair Generation 6.1.1.2 RA Key Pair Generation 6.1.1.3 Subscriber Key Pair Generation 6.1.2 Private key delivery to subscriber 6.1.3 Public key delivery to certificate issuer 6.1.4 CA public key delivery to relying parties 6.1.5 Key sizes

6.1.5.1 Root CA Certificates 6.1.5.2 Subordinate CA Certificates 6.1.5.3 Subscriber Certificates

6.1.6 Public key parameters generation and quality checking 6.1.7 Key usage purposes (as per X.509 v3 key usage field)

6.2 Private Key Protection and Cryptographic Module Engineering Controls 6.2.1 Cryptographic module standards and controls

6.2.2 Private key (n out of m) multi-person control 6.2.3 Private key escrow

6.2.4 Private key backup 6.2.5 Private key archival

6.2.6 Private key transfer into or from a cryptographic module 6.2.7 Private key storage on cryptographic module

6.2.8 Method of activating private key 6.2.9 Method of deactivating private key 6.2.10 Method of destroying private key 6.2.11 Cryptographic Module Rating 6.3 Other aspects of key pair management 6.3.1 Public key archival

6.3.2 Certificate operational periods and key pair usage periods 6.4 Activation data

(7)

6.4.2 Activation data protection 6.4.3 Other aspects of activation data 6.5 Computer security controls

6.5.1 Specific computer security technical requirements 6.5.1.1 Account Management

6.5.1.2 Least Privilege

6.5.1.3 Access Control Best Practices

6.5.1.4 Authentication: Passwords and Accounts 6.5.1.5 System Isolation and Partitioning 6.5.1.6 Malicious Code Protection 6.5.1.7 Software and Firmware Integrity 6.5.2 Computer security rating

6.6 Life cycle technical controls 6.6.1 System development controls 6.6.2 Security management controls 6.6.3 Life cycle security controls 6.7 Network security controls 6.7.1 Boundary Systems

6.7.1.1 PKI Network Zones Overview 6.7.1.2 Special Access Zone Boundary 6.7.1.3 Restricted Zone Boundary 6.7.1.4 Operational Zone Boundary 6.7.2 Network Monitoring

6.7.2.1 Monitoring devices

6.7.2.2 Monitoring of Security Alerts, Advisories, and Directives 6.7.3 Remote Access/External Information Systems

6.7.4 Penetration Testing 6.8 Time-stamping

7 CERTIFICATE, CRL, AND OCSP PROFILES 7.1 Certificate profile

7.1.1 Version number(s) 7.1.2 Certificate extensions 7.1.2.1 Root CA Certificate 7.1.2.2 Subordinate CA Certificate 7.1.2.3 Subscriber Certificate 7.1.2.4 All Certificates

7.1.2.5 Application of RFC 5280 7.1.3 Algorithm object identifiers 7.1.4 Name forms

7.1.4.1 Issuing CA Certificate Subject

7.1.4.2 Subject Information for Standard Server Authentication certificates 7.1.4.3 Subject Alternative Names for Standard Server Authentication certificates 7.1.4.4 Subject Information for Extended Validation Server Authentication certificates 7.1.4.5 Subject Alternative Names for Extended Valdation Server Authentication certificates 7.1.4.6 Subject Information for Extended Validation Code Signing certificates

(8)

7.1.6 Certificate policy object identifier 7.1.6.1. Reserved Certificate Policy Identifiers 7.1.6.2. Root CA Certificates

7.1.6.3 Subordinate CA Certificates 7.1.6.4 Subscriber Certificates

7.1.7 Usage of Policy Constraints extension 7.1.8 Policy qualifiers syntax and semantics

7.1.9 Processing semantics for the critical Certificate Policies extension 7.2 CRL profile

7.2.1 Version number(s)

7.2.2 CRL and CRL entry extensions 7.3 OCSP profile

7.3.1 Version number(s) 7.3.2 OCSP extensions

8 COMPLIANCE AUDIT AND OTHER ASSESSMENTS 8.1 Frequency or circumstances of assessment

8.2 Identity/qualifications of assessor 8.3 Assessor’s relationship to assessed entity 8.4 Topics covered by assessment

8.5 Actions taken as a result of deficiency 8.6 Communication of results

8.7 Self-Audits

9 OTHER BUSINESS AND LEGAL MATTERS 9.1 Fees

9.1.1 Certificate issuance or renewal fees 9.1.2 Certificate access fees

9.1.3 Revocation or status information access fees 9.1.4 Fees for other services

9.1.5 Refund policy 9.2 Financial responsibility 9.2.1 Insurance coverage 9.2.2 Other assets

9.2.3 Insurance or warranty coverage for end-entities 9.3 Confidentiality of business information

9.3.1 Scope of confidential information

9.3.2 Information not within the scope of confidential information 9.3.3 Responsibility to protect confidential information

9.4 Privacy of personal information 9.4.1 Privacy plan

9.4.2 Information treated as private 9.4.3 Information not deemed private

9.4.4 Responsibility to protect private information 9.4.5 Notice and consent to use private information

9.4.6 Disclosure pursuant to judicial or administrative process 9.4.7 Other information disclosure circumstances

(9)

9.6 Representations and warranties 9.6.1 CA representations and warranties 9.6.2 RA representations and warranties 9.6.3 Subscriber representations and warranties 9.6.4 Relying party representations and warranties 9.6.5 Representations and warranties of other participants 9.7 Disclaimers of warranties

9.8 Limitations of liability 9.9 Indemnities

9.10 Term and termination 9.10.1 Term

9.10.2 Termination

9.10.3 Effect of termination and survival

9.11 Individual notices and communications with participants 9.12 Amendments

9.12.1 Procedure for amendment

9.12.2 Notification mechanism and period

9.12.3 Circumstances under which OID must be changed 9.13 Dispute resolution provisions

9.14 Governing law

9.15 Compliance with applicable law 9.16 Miscellaneous provisions 9.16.1 Entire agreement 9.16.2 Assignment 9.16.3 Severability

9.16.4 Enforcement (attorneys’ fees and waiver of rights) 9.16.5 Force Majeure

(10)

1 INTRODUCTION

1.1 Overview

This Certificate Policy is intended to communicate the minimum operating requirements for CAs in the Amazon PKI. By design, it closely follows the CA/Brower Forum Guidelines and Requirements and only deviates when an Application Software Supplier has requirements that are stricter than those published by the CA/Browser Forum.

This CP also includes the principles and criteria that CAs are required to follow according to the Trust Service Principles and Criteria for Certification Authorities Version 2.0.

This CP does not attempt to paraphrase or alter the requirements, rather the focus is to bring all of them into one document to enable Relying Parties and auditors to have a comprehensive view of the policies which the CA commits to follow.

Certificate Authorities following this CP may have practices which exceed the minimum requirements set forth by these policies. CAs may also describe practices that cover topics for which there is no stipulation in this CP.

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

1.1.1 Compliance

This Certificate Policy conforms to the current version of the Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates published at http://www.cabforum.org (http://

www.cabforum.org). In the event of any inconsistency between this document and those Requirements, those Requirements take precedence over this document.

This Certificate Policy conforms to the current version of the CA/Browser Forum Guidelines for Issuance and Management of Extended Validation Certificates published at http://www.cabforum.org. In the event of any inconsistency between this document and those Guidelines, those Guidelines take precedence over this document.

This CP conforms to the current version of the CA/Browser Forum Guidelines for Issuance and

Management of Extended Validation Code Signing Certificates published at http://www.cabforum.org. In the event of any inconsistency between this document and those Guidelines, those Guidelines take precedence over this document.

1.1.2 Types of Certificates

This Certificate Policy defines several different types of certificates. Each certificate issued under this policy is categorized as either a CA Certificate or a Subscriber Certificate.

(11)

1.1.2.1 CA Certificates

A certificate is a CA certificate if basicConstraints extension is present and has cA:TRUE.

1.1.2.1.1 Self-signed CA Certificates

A certificate is a Self-signed CA certificate if all the following are true: • The basicConstraints extension is present and has cA:TRUE • The subject and issuer DNs of the certificate match

• The certificate signature is validated by the subject public key

1.1.2.1.2 Intermediate CA Certificates

A certificate is an Intermediate CA certificate if all the following are true: • The basicConstraints extension is present and has cA:TRUE • It is not a Self-signed CA certificate

• The pathLenConstraint is either absent or is set to a non-zero value

1.1.2.1.3 Terminus CA Certificates

A certificate is a Terminus CA certificate if the basicConstraints extension is present and has cA:TRUE and the pathLenConstraint is present and set to 0 (zero).

1.1.2.1.4 Policy CA Certificates

A certificate is a Policy CA certificate if it is a CA certificate and is not a Terminus CA certificate.

1.1.2.1.5 Technically Constrained CA Certificates

A certificate is a Technically Constrained CA certificate if it is a CA certificate and it meets the requirements in section 7.1.5.

1.1.2.1.6 Unconstrained CA Certificates

A certificate is an Unconstrained CA certificate if it is a CA certificate and is not a Technically Constrained CA certificate.

(12)

1.1.2.1.7 Root CA Certificates

A certificate is a Root CA certificate if it an Unconstrained Policy CA certificate and is designated by the CA as a Root CA in the CA’s CPS.

1.1.2.1.8 Cross Certificates

A certificate is a Cross certificate if it is a CA certificate and the Subject Distinguished Name and Subject Public Key are the same as that of a Root CA Certificate.

1.1.2.1.9 Subordinate CA Certificates

A certificate is a Subordinate CA certificate if it is not a Cross certificate and is either an Intermediate CA certificate or Terminus CA certificate.

1.1.2.2 Subscriber Certificates

A certificate is a Subscriber Certificate if it is not a CA certificate.

Subscriber Certificates can be further broken down into the following categories. CAs must not issue Subscriber certificates that simultaneously meet the criteria of multiple of the following categories.

1.1.2.2.1 Extended Validation TLS Server Authentication Certificates

A Subscriber Certificate is an Extended Validation TLS Server Authentication Certificate if it (i) has a Relative Distinguished Name of type jurisdictionOfIncorporationCountryName (1.3.6.1.4.1.311.60.2.1.3) in the Subject Distinguished Name and (ii) has a key purpose of id-kp-serverAuth (1.3.6.1.5.5.7.3.1) in the Extended Key Usage certificate extension.

1.1.2.2.2 Standard Validation TLS Server Authentication Certificates

A Subscriber Certificate is a Standard Validation TLS Server Authentication Certificate if it (i) does not have a Relative Distinguished Name of type jurisdictionOfIncorporationCountryName (1.3.6.1.4.1.311.60.2.1.3) in the Subject Distinguished Name and (ii) has a key purpose of id-kp-serverAuth (1.3.6.1.5.5.7.3.1) in the Extended Key Usage certificate extension.

(13)

1.1.2.2.3 Extended Validation Code Signing Certificates

A Subscriber Certificate is an Extended Validation Code Signing Certificate if it (i) has a Relative Distinguished Name of type jurisdictionOfIncorporationCountryName (1.3.6.1.4.1.311.60.2.1.3) in the Subject Distinguished Name and (ii) has a key purpose of id-kp-codeSigning (1.3.6.1.5.5.7.3.3) in the Extended Key Usage certificate extension.

1.1.2.2.4 Standard Validation Code Signing Certificates

A Subscriber Certificate is an Extended Validation Code Signing Certificate if it (i) does not have a Relative Distinguished Name of type jurisdictionOfIncorporationCountryName (1.3.6.1.4.1.311.60.2.1.3) in the Subject Distinguished Name and (ii) has a key purpose of id-kp-codeSigning (1.3.6.1.5.5.7.3.3) in the Extended Key Usage certificate extension.

1.1.2.2.5 Client Certificates (including Augmented Client Certificates)

A Subscriber Certificate is a Client Certificate if it has at least one of kp-clientAuth (1.3.6.1.5.5.7.3.2), id-kp-emailProtection (1.3.6.1.5.5.7.3.4), Document Signing (1.3.6.1.4.1.311.10.3.12), or Encrypting Filesystem Crypto (1.3.6.1.4.1.311.10.3.4) key purposes in the Extended Key Usage certificate extension and does not have the id-kp-serverAuth (1.3.6.1.5.5.7.3.1) key purpose in the Extended Key Usage certificate extension. Under this policy, an Augmented Client Certificate is identical to a Client Certificate.

1.1.2.2.6 OCSP Signing Certificate

A Subscriber Certificate is an OCSP Signing Certificate if it has a key purpose of id-kp-OCSPSigning (1.3.6.1.5.5.7.3.9) in the Extended Key Usage certificate extension.

1.1.2.2.7 Time Stamp Authority Certificate

A Subscriber Certificate is a Time Stamping Authority Certificate if it has a key purpose of id-kp-timeStamping (1.3.6.1.5.5.7.3.8) in the Extended Key Usage certificate extension.

1.2 Document name and identification

This is the Amazon Public Key Infrastructure (PKI) Certificate Policy. It was approved for publication by the Amazon PKI Policy Management Authority (APPMA). Amendments are made only after the APPMA has reviewed and approved such amendment. This document is identified by the Object Identifier

1.3.187.16385.1.

This CP is updated at least annually to ensure that it incorporates the latest version of the CA/Browser Forum Baseline Requirements.

(14)

1.3 PKI participants

1.3.1 Certification authorities

The Certification Authority (CA) provides services in accordance with its disclosed practices.

1.3.2 Registration authorities

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:

1. Meet the qualification requirements of Section 5.3.1, when applicable to the delegated function; 2. Retain documentation in accordance with Section 5.5.2;

3. Abide by the other provisions of these Requirements that are applicable to the delegated function; and 4. Comply with (a) the CA’s Certificate Policy/Certification Practice Statement or (b) the Delegated

Third Party’s practice statement that the CA has verified complies with these Requirements. The CA MAY designate an Enterprise RA to verify certificate requests from the Enterprise RA’s own organization. The CA SHALL NOT accept certificate requests authorized by an Enterprise RA unless the following requirements are satisfied:

1. The CA SHALL confirm that the requested Fully-Qualified Domain Name(s) are within the Enterprise RA’s verified Domain Namespace.

2. If the certificate request includes a Subject name of a type other than a Fully-Qualified Domain Name, the CA SHALL confirm that the name 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. For example, the CA SHALL NOT issue a Certificate containing the Subject name “XYZ Co.” on the authority of Enterprise RA “ABC Co.”, unless the two companies are affiliated (see Section 3.2) or “ABC Co.” is the agent of “XYZ Co”. This requirement applies regardless of whether the accompanying requested Subject FQDN falls within the Domain Namespace of ABC Co.’s Registered Domain Name. The CA SHALL impose these limitations as a contractual requirement on the Enterprise RA and monitor compliance by the Enterprise RA.

The CA MAY contractually authorize the Subject of a specified Valid EV Certificate to perform the RA function and authorize the CA to issue Enterprise EV Certificates. In such case, the Subject SHALL be considered an Enterprise RA, and the following requirements SHALL apply:

1. An Enterprise RA SHALL NOT authorize the CA to issue an Enterprise EV Certificate at the third or higher domain levels to any Subject other than the Enterprise RA or a business that is owned or directly controlled by the Enterprise RA;

2. In all cases, the Subject of an Enterprise EV Certificate MUST be an organization verified by the CA in accordance with this Certificate Policy;

3. The CA MUST impose these limitations as a contractual requirement with the Enterprise RA and monitor compliance by the Enterprise RA;

(15)

4. The Final Cross-Correlation and Due Diligence requirements of EV Guidelines Section 11.13 MAY be performed by a single person representing the Enterprise RA; and

5. The audit requirements of EV Guidelines Section 17.1 SHALL apply to the Enterprise RA, except in the case where the CA maintains control over the Root CA Private Key or Subordinate CA Private Key used to issue the Enterprise EV Certificates, in which case, the Enterprise RA MAY be exempted from the audit requirements.

The CA MAY NOT contractually authorize the Subject of a specified Valid EV Code Signing Certificate to perform the RA function and authorize the CA to issue additional EV Code Signing Certificates.

1.3.3 Subscribers

No stipulation.

1.3.4 Relying parties

No stipulation.

1.3.5 Other participants

The CA MUST include (directly or by reference) the applicable requirements of the EV Guidelines in all contracts with Subordinate CAs, RAs, Enterprise RAs, and subcontractors that involve or relate to the issuance or maintenance of EV Certificates. The CA MUST enforce compliance with such terms. In all cases, the CA MUST contractually obligate each Affiliate, RA, subcontractor, and Enterprise RA to comply with all applicable requirements in this CP and to perform them as required of the CA itself. The CA SHALL enforce these obligations and internally audit each Affiliate’s, RA’s, subcontractor’s, and Enterprise RA’s compliance with these Requirements on an annual basis.

The CA MUST include (directly or by reference) the applicable requirements of this Certificate Policy in all contracts that involve or relate to the issuance or maintenance of EV Code Signing Certificates. The Issuer MUST enforce compliance with such terms.

In all cases, the CA MUST contractually obligate each RA and subcontractor to comply with all applicable requirements in this Certificate Policy and to perform them as required of the CA itself. The CA SHALL enforce these obligations and internally audit each Affiliate’s, RA’s, and subcontractor’s compliance with these Requirements on an annual basis.

1.4 Certificate usage

1.4.1 Appropriate certificate uses

No stipulation.

1.4.2 Prohibited certificate uses

(16)

1.5 Policy administration

The CA must disclose its business practices including but not limited to the topics listed in RFC 3647, RFC 2527, or WebTrust for Certification Authorities v1 CA Business Practices Disclosure Criteria in its Certification Practice Statement.

The CA must maintain controls to provide reasonable assurance that its Certification Practice Statement management processes are effective.

Each CA MUST develop, implement, enforce, display prominently on its Web site, and periodically update as necessary its own auditable EV Certificate practices, policies and procedures that:

1. Implements this policy;

2. Implements the requirements of (i) the current WebTrust Program for CAs, and (ii) the then-current WebTrust EV Program or ETSI TS 102 042; and

3. Specifies the CA’s and its Root CA’s entire root certificate hierarchy including all roots that its EV Certificates depend on for proof of those EV Certificates’ authenticity.

Each Issuer MUST develop, implement, enforce, display prominently on its Web site, and periodically update as necessary its own auditable EV Code Signing Object practices, policies and procedures, such as a

Certification Practice Statement and Certificate Policy that:

A. Implement the requirements of this Certificate Policy as they are revised from time-to-time; B. Implement the requirements of (i) the current WebTrust Program for CAs, and (ii) the

then-current WebTrust EV Program or ETSI TS 102 042 V2.1.1; and

C. Specify the Issuer’s (and applicable Root CA’s) entire root certificate hierarchy including all roots that its EV Code Signing Certificates depend on for proof of those EV Code Signing Certificates’

authenticity.

With the exception of revocation checking for time-stamped and expired certificates, platforms are expected to validate signed code in accordance with RFC 5280. When a platform encounters a certificate that fails to validate due to revocation, the platform should reject the code. When a platform encounters a certificate that fails to validate for reasons other than revocation, the platform should treat the code as it would if it had been unsigned.

Ordinarily, a code signature created by a Subscriber may be considered valid for a period of up to thirty-nine months. However, a code signature may be treated as valid for a period of up to one hundred and twenty three months by means of one of the following methods: the “Timestamp” Method or the “Signing Authority” Method.

A. _{Timestamp Method}_{: In this method, the Subscriber signs the code, appends its EV Code Signing} Certificate (whose expiration time is less than thirty-nine months in the future) and submits it to an EV Timestamp Authority to be time-stamped. The resulting package can be considered valid up to the expiration time of the timestamp certificate (which may be up to one hundred and twenty three months in the future).

B. Signing Authority Method: In this method, the Subscriber submits the code, or a digest of the code, to an EV Signing Authority for signature. The resulting signature is valid up to the expiration time of

(17)

the Signing Authority certificate (which may be up to one hundred and twenty three months in the future).

1.5.1 Organization administering the document

No stipulation.

1.5.2 Contact person

No stipulation.

1.5.3 Person determining CPS suitability for the policy

The CA must maintain controls to provide reasonable assurance that its Certification Practice Statement addresses the topics included in its Certificate Policy.

1.5.4 CPS approval procedures

No stipulation.

1.6 Definitions and acronyms

1.6.1 Definitions

Accounting Practitioner

A certified public accountant, chartered accountant, or a person with an equivalent license within the country of the Applicant’s Jurisdiction of Incorporation or Registration or any jurisdiction where the Applicant maintains an office or physical facility; provided that an accounting standards body in the jurisdiction maintains full (not “suspended” or “associate”) membership status with the International Federation of Accountants.

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: (i) who signs and submits, or approves a certificate request on behalf of the Applicant, and/or (ii) who signs and submits a Subscriber Agreement on behalf of the Applicant, and/or (iii) who acknowledges and agrees to the Certificate Terms of Use on behalf of the Applicant when the Applicant is an Affiliate of the CA. Application Software Supplier

A supplier of Internet browser software or other relying-party application software that displays or uses Certificates and incorporates Root Certificates.

(18)

Attestation Letter

A letter attesting that Subject Information is correct written by an accountant, lawyer, government official, or other reliable third party customarily relied upon for such information.

Audit 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 the Baseline Requirements. Baseline Requirements

The Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates as published by the CA/Browser Forum and any amendments to such document.

Business Entity

Any entity that is not a Private Organization, Government Entity, or Non-Commercial Entity as defined herein. Examples include, but are not limited to, general partnerships, unincorporated associations, sole proprietorships, etc.

CAA Record

From RFC 6844 (http:tools.ietf.org/html/rfc6844): “The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify the Certification Authorities (CAs) authorized to issue certificates for that domain. Publication of CAA Resource Records allows a public Certification Authority to implement additional controls to reduce the risk of unintended certificate mis-issue.”

Certificate

An electronic document that uses a digital signature to bind a public key and an identity. Certificate Approver

A natural person who is either the Applicant, employed by the Applicant, or an authorized agent who has express authority to represent the Applicant to (i) act as a Certificate Requester and to authorize other employees or third parties to act as a Certificate Requester, and (ii) to approve EV Certificate Requests submitted by other Certificate Requesters.

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 Management System

A system used by a CA or Delegated Third Party to process, approve issuance of, or store certificates or certificate status information, including the database, database server, and storage.

Certificate Policy

A set of rules that indicates the applicability of a named Certificate to a particular community and/or PKI implementation with common security requirements.

Certificate Problem Report

Complaint of suspected Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, or inappropriate conduct related to Certificates.

Certificate Requester

A natural person who is either the Applicant, employed by the Applicant, an authorized agent who has express authority to represent the Applicant, or a third party (such as an ISP or hosting company) that completes and submits an EV Certificate Request on behalf of the Applicant.

(19)

A regularly updated time-stamped list of revoked Certificates that is created and digitally signed by the CA that issued the Certificates.

Certificate Systems

The system used by a CA or Delegated Third Party in providing identity verification, registration and enrollment, certificate approval, issuance, validity status, support, and other PKI-related services. Certification Authority

An organization that is responsible for the creation, issuance, revocation, and management of Certificates. The term applies equally to both Roots CAs and Subordinate CAs.

Certification Practice Statement

One of several documents forming the governance framework in which Certificates are created, issued, managed, and used.

Common Vulnerability Scoring System (CVSS)

A quantitative model used to measure the base level severity of a vulnerability (see http://nvd.nist.gov/ home.cfm).

Confirmation Request

An appropriate out-of-band communication requesting verification or confirmation of the particular fact at issue.

Confirming Person

A position within an Applicant’s organization that confirms the particular fact at issue. Contract Signer

A natural person who is either the Applicant, employed by the Applicant, or an authorized agent who has express authority to represent the Applicant, and who has authority on behalf of the Applicant to sign Subscriber Agreements.

Control

“Control” (and its correlative meanings, “controlled by” and “under common control with”) means possession, directly or indirectly, of the power to: (1) direct the management, personnel, finances, or plans of such entity; (2) control the election of a majority of the directors; or (3) vote that portion of voting shares required for “control” under the law of the entity’s Jurisdiction of Incorporation or Registration but in no case less than 10%.

Country

Either a member of the United Nations OR a geographic region recognized as a sovereign nation by at least two UN member nations.

Critical Security Event

Detection of an event, a set of circumstances, or anomalous activity that could lead to a circumvention of a Zone’s security controls or a compromise of a Certificate System’s integrity, including excessive login attempts, attempts to access prohibited resources, DoS/DDoS attacks, attacker reconnaissance, excessive traffic at unusual hours, signs of unauthorized access, system intrusion, or an actual compromise of component integrity.

Critical Vulnerability

A system vulnerability that has a CVSS score of 7.0 or higher according to the NVD or an equivalent to such CVSS rating (see http://nvd.nist.gov/home.cfm), or as otherwise designated as a Critical

Vulnerability by the CA or the CA/Browser Forum. Cross Certificate

A certificate that is used to establish a trust relationship between two Root CAs. Delegated Third Party

(20)

A natural person or Legal Entity that is not the CA but is authorized by the CA to assist in the Certificate Management Process by performing or fulfilling one or more of the CA requirements found herein.

Delegated Third Party System

Any part of a Certificate System used by a Delegated Third Party while performing the functions delegated to it by the CA.

Demand Deposit Account

A deposit account held at a bank or other financial institution, the funds deposited in which are payable on demand. The primary purpose of demand accounts is to facilitate cashless payments by means of check, bank draft, direct debit, electronic funds transfer, etc. Usage varies among countries, but a demand deposit account is commonly known as a share draft account, a current account, or a checking account.

Domain Authorization Document

Documentation provided by, or a CA’s documentation of a communication with, a Domain Name Registrar, the Domain Name Registrant, or the person or entity listed in WHOIS as the Domain Name Registrant (including any private, anonymous, or proxy registration service) attesting to the authority of an Applicant to request a Certificate for a specific Domain Namespace.

Domain Name

The label assigned to a node in the Domain Name System. Domain Name Registrant

Sometimes referred to as the “owner” of a Domain Name, but more properly the person(s) or entity (ies) registered with a Domain Name Registrar as having the right to control how a Domain Name is used, such as the natural person or Legal Entity that is listed as the “Registrant” by WHOIS or the Domain Name Registrar.

Domain Name Registrar

A person or entity that registers Domain Names under the auspices of or by agreement with: (i) the Internet Corporation for Assigned Names and Numbers (ICANN), (ii) a national Domain Name authority/registry, or (iii) a Network Information Center (including their affiliates, contractors, delegates, successors, or assigns).

Domain Namespace

The set of all possible Domain Names that are subordinate to a single node in the Domain Name System.

Enterprise EV Certificate

An EV Certificate that an Enterprise RA authorizes the CA to issue at third and higher domain levels. Enterprise EV RA

An RA that is authorized by the CA to authorize the CA to issue EV Certificates at third and higher domain levels.

Enterprise RA

An employee or agent of an organization unaffiliated with the CA who authorizes issuance of Certificates to that organization.

EV Authority

A source other than the Certificate Approver, through which verification occurs that the Certificate Approver is expressly authorized by the Applicant, as of the date of the EV Certificate Request, to take the Request actions described in the EV Guidelines.

EV Certificate

A certificate that contains subject information specified in the EV Guidelines and that has been validated in accordance with the EV Guidelines.

(21)

EV Certificate Beneficiaries

Persons to whom the CA and its Root CA make specified EV Certificate Warranties. EV Certificate Reissuance

The process whereby an Applicant who has a valid unexpired and non-revoked EV Certificate makes an application, to the CA that issued the original certificate, for a newly issued EV Certificate for the same organizational name and Domain Name prior to the expiration of the Applicant’s existing EV Certificate but with a ‘valid to’ date that matches that of the current EV Certificate.

EV Certificate Renewal

The process whereby an Applicant who has a valid unexpired and non-revoked EV Certificate makes an application, to the CA that issued the original certificate, for a newly issued EV Certificate for the same organizational name and Domain Name prior to the expiration of the Applicant’s existing EV Certificate but with a new ‘valid to’ date beyond the expiry of the current EV Certificate.

EV Certificate Request

A request from an Applicant to the CA requesting that the CA issue an EV Certificate to the Applicant, which request is validly authorized by the Applicant and signed by the Applicant Representative. EV Certificate Warranties

In conjunction with the CA issuing an EV Certificate, the CA and its Root CA, during the period when the EV Certificate is Valid, promise that the CA has followed the requirements of the EV Guidelines and the CA’s EV Policies in issuing the EV Certificate and in verifying the accuracy of the information contained in the EV Certificate.

EV Code Signing Certificate

A certificate that contains subject information specified in this Certificate Policy and that has been validated in accordance with this Certificate Policy.

EV Code Signing Object

An EV Code Signing Certificate issued by a CA or an EV Signature provided by a Signing Authority. EV Guidelines

Guidelines For The Issuance And Management Of Extended Validation Certificates published by the CA/ Browser Forum

EV OID

An identifying number, in the form of an “object identifier,” that is included in the certificatePolicies field of a certificate that: (i) indicates which CA policy statement relates to that certificate, and (ii) by pre-agreement with one or more Application Software Supplier, marks the certificate as being an EV Certificate.

EV Policies

Auditable EV Certificate practices, policies and procedures, such as a certification practice statement and certificate policy, that are developed, implemented, and enforced by the CA and its Root CA. EV Processes

The keys, software, processes, and procedures by which the CA verifies Certificate Data under the EV Guidelines, issues EV Certificates, maintains a Repository, and revokes EV Certificates.

EV Signature

An encrypted electronic data file which is attached to or logically associated with other electronic data and which (i) identifies and is uniquely linked to the signatory of the electronic data, (ii) is created using means that the signatory can maintain under its sole control, and (iii) is linked in a way so as to make any subsequent changes that have been made to the electronic data detectable.

Expiry Date

The “Not After” date in a Certificate that defines the end of a Certificate’s validity period. Extended Validation Certificate

(22)

See EV Certificate.

Front End / Internal Support System

A system with a public IP address, including a web server, mail server, DNS server, jump host, or authentication server.

Fully-Qualified Domain Name

A Domain Name that includes the labels of all superior nodes in the Internet Domain Name System. Government Agency

In the context of a Private Organization, the government agency in the Jurisdiction of Incorporation under whose authority the legal existence of Private Organizations is established (e.g., the government agency that issued the Certificate of Incorporation). In the context of Business Entities, the

government agency in the jurisdiction of operation that registers business entities. In the case of a Government Entity, the entity that enacts law, regulations, or decrees establishing the legal existence of Government Entities.

Government Entity

A government-operated legal entity, agency, department, ministry, branch, or similar element of the government of a country, or political subdivision within such country (such as a state, province, city, county, etc.).

High Risk Certificate Request

A Request that the CA flags for additional scrutiny by reference to internal criteria and databases maintained by the CA, which may include names at higher risk for phishing or other fraudulent usage, names contained in previously rejected certificate requests or revoked Certificates, names listed on the Miller Smiles phishing list or the Google Safe Browsing list, or names that the CA identifies using its own risk-mitigation criteria.

High Security Zone

A physical location where a CA’s or Delegated Third Party’s Private Key or cryptographic hardware is located.

Incorporating Agency

In the context of a Private Organization, the government agency in the Jurisdiction of Incorporation under whose authority the legal existence of the entity is registered (e.g., the government agency that issues certificates of formation or incorporation). In the context of a Government Entity, the entity that enacts law, regulations, or decrees establishing the legal existence of Government Entities. Independent Confirmation From Applicant

Confirmation of a particular fact received by the CA pursuant to the provisions of the EV Guidelines or binding upon the Applicant.

Individual

A natural person. Internal Name

A string of characters (not an IP address) in a Common Name or Subject Alternative Name field of a Certificate that cannot be verified as globally unique within the public DNS at the time of certificate issuance because it does not end with a Top Level Domain registered in IANA’s Root Zone Database. International Organization

An organization founded by a constituent document, e.g., a charter, treaty, convention or similar document, signed by, or on behalf of, a minimum of two Sovereign State governments.

Issuer

A CA providing an EV Code Signing Certificate to a Subscriber or a Signing Authority that provides an EV signature for a Subscriber.

(23)

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

Issuing System

A system used to sign certificates or validity status information. Jurisdiction of Incorporation

In the context of a Private Organization, 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.

Jurisdiction of Registration

In the case of a Business Entity, the state, province, or locality where the organization has registered its business presence by means of filings by a Principal Individual involved in the business.

Key Compromise

A Private Key is said to be compromised if its value has been disclosed to an unauthorized person, an unauthorized person has had access to it, or there exists a practical technique by which an

unauthorized person may discover its value. A Private Key is also considered compromised if methods have been developed that can easily calculate it based on the Public Key (such as a Debian weak key, see http://wiki.debian.org/SSLkeys) or if there is clear evidence that the specific method used to generate the Private Key was flawed.

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. Latin Notary

A person with legal training whose commission under applicable law not only includes authority to authenticate the execution of a signature on a document but also responsibility for the correctness and content of the document. A Latin Notary is sometimes referred to as a Civil Law Notary.

Legal Entity

An association, corporation, partnership, proprietorship, trust, government entity or other entity with legal standing in a country’s legal system.

Legal Existence

A Private Organization, Government Entity, or Business Entity has Legal Existence if it has been validly formed and not otherwise terminated, dissolved, or abandoned.

Legal Practitioner

A person who is either a lawyer or a Latin Notary as described in the EV Guidelines and competent to render an opinion on factual claims of the Applicant.

Maximum Validity Period

1. The maximum time period for which the issued EV Certificate is valid. 2. The maximum period after validation by the CA that certain Applicant information may be relied upon in issuing an EV Certificate pursuant to the EV Guidelines.

National Vulnerability Database (NVD)

A database that includes the Common Vulnerability Scoring System (CVSS) scores of security-related software flaws, misconfigurations, and vulnerabilities associated with systems (see http://nvd.nist.gov/ home.cfm).

(24)

A person whose commission under applicable law includes authority to authenticate the execution of a signature on a document.

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.

OWASP Top Ten

A list of application vulnerabilities published by the Open Web Application Security Project (see https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project).

Parent CA

The CA which issues a Subordinate CA Certificate Parent Company

A company that Controls a Subsidiary Company. Penetration Test

A process that identifies and attempts to exploit openings and vulnerabilities on systems through the active use of known attack techniques, including the combination of different types of exploits, with a goal of breaking through layers of defenses and reporting on unpatched vulnerabilities and system weaknesses.

Place of Business

The location of any facility (such as a factory, retail store, warehouse, etc) where the Applicant’s business is conducted.

Principal Individual

An individual of a Private Organization, Government Entity, or Business Entity that is either an owner, partner, managing member, director, or officer, as identified by their title of employment, or an employee, contractor or agent authorized by such entity or organization to conduct business related to the request, issuance, and use of EV Certificates.

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.

Private Organization

A non-governmental legal entity (whether ownership interests are privately held or publicly traded) whose existence was created by a filing with (or an act of) the Incorporating Agency or equivalent in its Jurisdiction of Incorporation.

Public Key

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

corresponding Private Key. Public Key Infrastructure

(25)

A set of hardware, software, people, procedures, rules, policies, and obligations used to facilitate the trustworthy creation, issuance, management, and use of Certificates and keys based on Public Key Cryptography.

Publicly-Trusted Certificate

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

Qualified Auditor

A natural person or Legal Entity that meets the requirements of Section 8.2. Qualified Government Information Source

A database maintained by a Government Entity (e.g. SEC filings) that meets the requirements of Section 11.11.6 of the EV Guidelines.

Qualified Government Tax Information Source

A Qualified Governmental Information Source that specifically contains tax information relating to Private Organizations, Business Entities, or Individuals.

Qualified Independent Information Source

A regularly-updated and current, publicly available, database designed for the purpose of accurately providing the information for which it is consulted, and which is generally recognized as a dependable source of such information.

Registered Agent

An individual or entity that is: (i) authorized by the Applicant to receive service of process and business communications on behalf of the Applicant; and (ii) listed in the official records of the Applicant’s Jurisdiction of Incorporation as acting in the role specified in (i) above.

Registered Domain Name

A Domain Name that has been registered with a Domain Name Registrar. Registered Office

The official address of a company, as recorded with the Incorporating Agency, to which official documents are sent and at which legal notices are received

Registration Agency

A Governmental Agency that registers business information in connection with an entity’s business formation or authorization to conduct business under a license, charter or other certification. A Registration Agency MAY include, but is not limited to (i) a State Department of Corporations or a Secretary of State; (ii) a licensing agency, such as a State Department of Insurance; or (iii) a chartering agency, such as a state office or department of financial regulation, banking or finance, or a federal agency such as the Office of the Comptroller of the Currency or Office of Thrift Supervision. 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.

Registration Number

The unique number assigned to a Private Organization by the Incorporating Agency in such entity’s Jurisdiction of Incorporation.

Regulated Financial Institution

A financial institution that is regulated, supervised, and examined by governmental, national, state or provincial, or local authorities.

(26)

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.

Reserved IP Address

An IPv4 or IPv6 address that the IANA has marked as reserved: http://www.iana.org/assignments/ ipv4-address-space/ipv4-address-space.xml (http://www.iana.org/assignments/ipv4-address-space/ ipv4-address-space.xml) http://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xml (http://www.iana.org/assignments/ipv6-address-space/ipv6-address-http://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xml) Root CA

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

Root CA System

A system used to create a Root Certificate or to generate, store, or sign with the Private Key associated with a Root Certificate.

Root Certificate

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

Root Key Generation Script

A documented plan of procedures to be performed for the generation of the Root CA Key Pair. SANS Top 25

A list created with input from the SANS Institute and the Common Weakness Enumeration (CWE) that identifies the Top 25 Most Dangerous Software Errors that lead to exploitable vulnerabilities (see http://www.sans.org/top25-software-errors/).

Secure Zone

An area (physical or logical) protected by physical and logical controls that appropriately protect the confidentiality, integrity, and availability of Certificate Systems.

Security Support System

A system used to provide security support functions, such as authentication, network boundary control, audit logging, audit log reduction and analysis, vulnerability scanning, and antivirus. Signing Authority

One or more Certificate Approvers designated to act on behalf of the Applicant. Sovereign State

A state or country that administers its own government, and is not dependent upon, or subject to, another power.

(27)

The natural person, device, system, unit, or Legal Entity identified in a Certificate as the Subject. The Subject is either the Subscriber or a device under the control and operation of the Subscriber.

Subject Identity Information

Information that identifies the Certificate Subject. Subject Identity Information does not include a domain name listed in the subjectAltName extension or the Subject commonName field.

Subordinate CA

A Certification Authority whose Certificate is signed by the Root CA, or another Subordinate CA. Subscriber

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

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. Superior Government Entity

Based on the structure of government in a political subdivision, the Government Entity or Entities that have the ability to manage, direct and control the activities of the Applicant.

Suspect code

Code that contains malicious functionality or serious vulnerabilities, including spyware, malware and other code that installs without the user’s consent and/or resists its own removal, and code that can be exploited in ways not intended by its designers to compromise the trustworthiness of the platforms on which it executes.

System

One or more pieces of equipment or software that stores, transforms, or communicates data. 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 Subscriber or additional Subordinate CA Certificates.

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.

Timestamp Authority

An organization that timestamps data, thereby asserting that the data existed at the specified time; Translator

An individual or Business Entity that possesses the requisite knowledge and expertise to accurately translate the words of a document written in one language to the native language of the CA. Trusted Role

An employee or contractor of a CA or Delegated Third Party who has authorized access to or control over a Secure Zone or High Security Zone.

Trustworthy System

Computer hardware, software, and procedures that are: reasonably secure from intrusion and misuse; provide a reasonable level of availability, reliability, and correct operation; are reasonably suited to performing their intended functions; and enforce the applicable security policy.

Unregistered Domain Name

A Domain Name that is not a Registered Domain Name. Valid Certificate

(28)

A Certificate that passes the validation procedure specified in RFC 5280. Validation Specialists

Someone who performs the information verification duties specified by this CP. Validity Period

The period of time measured from the date when the Certificate is issued until the Expiry Date. Verified Accountant Letter

A document meeting the requirements specified in Section 11.11.2 of the EV Guidelines Verified Legal Opinion

A document meeting the requirements specified in Section 11.11.1 of the EV Guidelines. Verified Method of Communication

The use of a telephone number, a fax number, an email address, or postal delivery address, confirmed by the CA in accordance with Section 11.5 of the EV Guidelines as a reliable way of communicating with the Applicant.

Vulnerability Scan

A process that uses manual or automated tools to probe internal and external systems to check and report on the status of operating systems, services, and devices exposed to the network and the presence of vulnerabilities listed in the NVD, OWASP Top Ten, or SANS Top 25.

WebTrust EV Program

The additional audit procedures specified for CAs that issue EV Certificates by the AICPA/CICA to be used in conjunction with its WebTrust Program for Certification Authorities.

WebTrust Program for CAs

The then-current version of the AICPA/CICA WebTrust Program for Certification Authorities. WebTrust Seal of Assurance

An affirmation of compliance resulting from the WebTrust Program for CAs. Wildcard Certificate

A Certificate containing an asterisk (*) in the left-most position of any of the Subject Fully-Qualified Domain Names contained in the Certificate.

Zone

A subset of Certificate Systems created by the logical or physical partitioning of systems from other Certificate Systems.

1.6.2 Acronyms

ADF

Application Data File AICPA

American Institute of Certified Public Accountants BIPM

International Bureau of Weights and Measures BIS

(US Government) Bureau of Industry and Security CA

Certification Authority CAA

Certification Authority Authorization ccTLD

(29)

CEO

Chief Executive Officer CFO

Chief Financial Officer CICA

Canadian Institute of Chartered Accountants CIO

Chief Information Officer CISO

Chief Information Security Officer COO

Chief Operating Officer CP

Certificate Policy CPA

Chartered Professional Accountant CPS

Certification Practice Statement CRL

Certificate Revocation List CSO

Chief Security Officer DBA

Doing Business As DNS

Domain Name System ETSI

European Telecommunications Standards Institute EV

Extended Validation FIPS

(US Government) Federal Information Processing Standard FQDN

Fully Qualified Domain Name gTLD

Generic Top-Level Domain IANA

Internet Assigned Numbers Authority ICANN

Internet Corporation for Assigned Names and Numbers ICC

Integrated Circuit Card IFAC

International Federation of Accountants IM

Instant Messaging IRS

(30)

Internal Revenue Service ISO

International Organization for Standardization ISP

Internet Service Provider NIST

(US Government) National Institute of Standards and Technology OCSP

Online Certificate Status Protocol OID

Object Identifier PKI

Public Key Infrastructure QGIS

Qualified Government Information Source QIIS

Qualified Independent Information Source QTIS

Qualified Government Tax Information Source RA

Registration Authority S/MIME

Secure MIME (Multipurpose Internet Mail Extensions) SEC

(US Government) Securities and Exchange Commission SSL

Secure Sockets Layer TLD

Top-Level Domain TLS

Transport Layer Security UTC(k)

National realization of Coordinated Universal Time VOIP

Voice Over Internet Protocol

1.6.3 References

ETSI TS 119 403, Electronic Signatures and Infrastructures (ESI); Trust Service Provider Conformity Assessment - General Requirements and Guidance.

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

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

(31)

ISO 21188:2006, Public key infrastructure for financial services – Practices and policy framework. NIST SP 800-89, Recommendation for Obtaining Assurances for Digital Signature Applications, http:// csrc.nist.gov/publications/nistpubs/800-89/SP-800-89_November2006.pdf.

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

RFC2527, Request for Comments: 2527, Internet X.509 Public Key Infrastructure: Certificate Policy and Certification Practices Framework, Chokhani, et al, March 1999.

RFC2560, Request for Comments: 2560, X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP M. Myers, et al, June 1999.

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

RFC4366, Request for Comments: 4366, Transport Layer Security (TLS) Extensions, Blake-Wilson, et al, April 2006.

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

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

WebTrust for Certification Authorities, SSL Baseline with Network Security, Version 2.0, available at http:// www.webtrust.org/homepage-documents/item79806.pdf.

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

1.6.4 Conventions

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in these Requirements shall be interpreted in accordance with RFC 2119.

2 PUBLICATION AND REPOSITORY RESPONSIBILITIES

The CA SHALL develop, implement, enforce, and annually update a Certification Practice Statement that describes in detail how the CA implements the latest version of these Requirements.

2.1 Repositories

The CA SHALL make revocation information for Subordinate Certificates and Subscriber Certificates available in accordance with this Policy.

(32)

2.2 Publication of certification information

The Parent CA maintains controls to provide reasonable assurance that timely, complete and accurate certificate status information (including CRLs and other certificate status mechanisms) is made available to any entity in accordance with the CA’s disclosed business practices.

The CA SHALL publicly disclose its Certificate Policy and/or Certification Practice Statement through an appropriate and readily accessible online means that is available on a 24x7 basis. The CA SHALL publicly disclose its CA business practices to the extent required by the CA’s selected audit scheme (see Section 8.1). The disclosures MUST include all the material required by RFC 2527 or RFC 3647, and MUST be structured in accordance with either RFC 2527 or RFC 3647. Effective as of 15 April 2015, section 4.2 of a CA’s

Certificate Policy and/or Certification Practice Statement (section 4.1 for CAs still conforming to RFC 2527) SHALL state whether the CA reviews CAA Records, and if so, the CA’s policy or practice on processing CAA Records for Fully Qualified Domain Names. The CA SHALL log all actions taken, if any, consistent with its processing practice.

The CA SHALL host test Web pages that allow Application Software Suppliers to test their software with Subscriber Certificates that chain up to each publicly trusted Root Certificate. At a minimum, the CA SHALL host separate Web pages using Subscriber Certificates that are (i) valid, (ii) revoked, and (iii) expired.

The CA MUST host test Web pages that allow Application Software Suppliers to test their software with EV Certificates that chain up to each EV Root Certificate. At a minimum, the CA MUST host separate Web pages using certificates that are (i) valid (ii) revoked and (iii) expired.

Each CA MUST publicly disclose their EV Policies through an appropriate and readily accessible online means that is available on a 24x7 basis. The CA is also REQUIRED to publicly disclose its CA business practices as required by both WebTrust for CAs and ETSI TS 102 042. The disclosures MUST be structured in accordance with either RFC 2527 or RFC 3647.

Amazon Web Services Certificate Policy. Version 1.0.1