First Call IT Services (FIRSTCALL)

Certification Practice Statement

Version 1.0
Updated June 9, 2020
Approved by the FIRSTCALL Policy Management Authority


1.1 Overview

This Certification Practice Statement ("CPS") document outlines the certification services practices for First Call IT Services ("FirstCall") Public Key Infrastructure ("FirstCall PKI").

FIRSTCALL PKI services include, but are not limited to, issuing, managing, validating, revoking, and renewing Certificates in accordance with the requirements of the FIRSTCALL Certificate Policy (CP). It is recommended that readers familiarize themselves with the FIRSTCALL CP prior to reading this document.

FIRSTCALL PKI services are most commonly, but not necessarily exclusively, provided under the brand/trademark "First Call IT Services".

The FIRSTCALL PKI conforms to the current version of the guidelines adopted by the Certification Authority/Browser Forum (“CAB Forum”) when issuing publicly trusted certificates, including the Baseline Requirements for the Issuance and Management of Publicly Trusted Certificates (“Baseline Requirements”). CAB Forum documents can be found at If there is any conflict between this CPS and a relevant CAB Forum requirement or guideline, then the CAB Forum requirement or guideline shall take precedence.

Other documents related to the behavior and control of the FIRSTCALL PKI, such as a Subscriber Agreement and Privacy Policy, can be found at

Per IETF PKIX RFC 3647, this CPS is divided into nine components that cover security controls, practices, and procedures for certification services provided by the FIRSTCALL PKI.

The following Certification Authorities are covered under this CPS:

CA Type

Distinguished Name

Key Pair Type and Parameters

SHA-256 Key Fingerprint

Validity Period

Root CA

O=First Call IT Services,
CN=First Call IT Services CA Root X1

RSA, n has 4096 bits, e=65537


Not Before: Jun 4 11:04:38 2015 GMT,
Not After: Jun 4 11:04:38 2035 GMT

This work is licensed under the Creative Commons Attribution 4.0 International License. To view a copy of this license, visit or send a letter to Creative Commons, PO Box 1866, Mountain View, CA 94042, USA.

1.2 Document name and identification

This is the FIRSTCALL Certification Practices Statement. and is made available at

The following revisions have been made:




June 6, 2020


















1.3 PKI participants

1.3.1 Certification authorities

FIRSTCALL is a CA that provides services including, but not limited to, issuing, managing, validating, revoking, and renewing publicly-trusted Certificates. These services are performed in accordance with the requirements of the FIRSTCALL Certificate Policy (CP) and this CPS. These services are provided to the general public with exceptions as deemed appropriate by FIRSTCALL management or in accordance with relevant law.

FIRSTCALL PKI services are most commonly, but not necessarily exclusively, provided under the brand/trademark "First Call IT Services".

1.3.2 Registration authorities

FIRSTCALL serves as its own RA. RA services are not performed by third parties.

1.3.3 Subscribers

See definition of "Subscriber" in Section 1.6.1 Definitions.

1.3.4 Relying parties

See definition of "Relying Party" in Section 1.6.1 Definitions.

Relying Parties must verify the validity of certificates via CRL or OCSP prior to relying on certificates. CRL and OCSP location information is provided within certificates.

1.3.5 Other participants

Other participants include CAs that cross-sign or issue subordinates to the FIRSTCALL PKI.

FIRSTCALL PKI vendors and service providers with access to confidential information or privileged systems are required to operate in compliance with the FIRSTCALL CP.

1.4 Certificate usage

1.4.1 Appropriate certificate uses

Certificates issued by FIRSTCALL PKI can be used only to establish secure online communication between hosts (as identified by the FQDN provided in the Certificate) and clients using the TLS protocol.

1.4.2 Prohibited certificate uses

Certificates may not be used:

·         For any purpose not explicitly defined in Section 1.4.1 of this document

·         For any application requiring fail-safe performance such as a) the operation of nuclear power facilities b) air traffic control systems c) aircraft navigation systems d) weapons control systems e) any other system in which failure could lead to injury, death, or environmental damage.

·         For software or hardware architectures that provide facilities for interference with encrypted communications, including but not limited to a) active eavesdropping (e.g., Man-in-the-middle attacks) b) traffic management of domain names or internet protocol (IP) addresses that the organization does not own or control. Note that these restrictions shall apply regardless of whether a relying party communicating through the software or hardware architecture has knowledge of its providing facilities for interference with encrypted communications.

·         When prohibited by law.

Also, note that Certificates do not guarantee anything regarding reputation, honesty, or the current state of endpoint security. A Certificate only represents that the information contained in it was verified as reasonably correct when the Certificate was issued.

1.5 Policy administration

1.5.1 Organization administering the document

This CPS document is maintained by the FIRSTCALL PMA.

1.5.2 Contact person

The FIRSTCALL PMA can be contacted at:

Policy Management Authority
First Call IT Services
975 Arthur Godfrey Rd Suite #600 Miami Beach FL,33140

1.5.3 Person determining CPS suitability for the policy

The FIRSTCALL PMA is responsible for determining the suitability of this CPS. The FIRSTCALL PMA is informed by results and recommendations received from an auditor.

1.5.4 CPS approval procedures

The FIRSTCALL PMA approves any revisions to this CPS document after formal review.

1.6 Definitions and acronyms

1.6.1 Definitions

·         ACME Protocol

o    A protocol used for validation, issuance, and management of certificates. The protocol is an open standard managed by the IETF.

·         Applicant

o    An entity applying for a certificate.

·         Baseline Requirements

o    A document published by the CAB Forum which outlines minimum requirements for publicly trusted Certificate Authorities.

·         CAB Forum

o    Certificate Authority / Browser Forum, a group a CAs and browsers which come together to discuss technical and policy issues related to PKI systems. (

·         Certificate Repository

o    A repository of information about FIRSTCALL certificates. It is located at:

·         Cross Certificate

o    A certificate that is used to establish a trust relationship between two Root CAs.

·         Policy and Legal Repository

o    A repository of policy and legal documents related to the FIRSTCALL PKI. It is located at:

·         Key Pair

o    A Private Key and its associated Public Key.

·         Private Key

o    The key in a Key Pair that must be kept secret. Used to create digital signatures that can be verified by the corresponding Public Key or to decrypt messages encrypted by the corresponding Public Key.

·         Public Key

o    The only key in a Key Pair that can safely be publicly disclosed. Used by Relying Parties to verify digital signatures from the corresponding private key or to encrypt messages that can only be decrypted by the corresponding private key.

·         Relying Party

o    An entity that relies upon information contained within certificates issued by FIRSTCALL PKI services.

·         Root CA

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

·         Secure PKI Facilities

o    Facilities designed to protect sensitive PKI infrastructure, including CA private keys.

·         Subscriber

o    An entity that has agreed to a Subscriber Agreement and is using FIRSTCALL PKI services.

·         Trusted Contributor

o    A contributor who performs in a Trusted Role. Trusted Contributors may be employees, contractors, or community members. Trusted Contributors must be properly trained and qualified, and have the proper legal obligations in place before performing in a Trusted Role.

·         Trusted Role

o    A role which qualifies a person to access or modify FIRSTCALL PKI systems, infrastructure, and confidential information.

1.6.2 Acronyms

·         ACME

o    Automated Certificate Management Environment

·         BRs

o    Baseline Requirements

·         CA

o    Certificate Authority

·         CAA

o    Certificate Authority Authorization

·         CP

o    Certificate Policy

·         CPS

o    Certification Practice Statement

·         DV

o    Domain Validation

·         FQDN

o    Fully Qualified Domain Name

·         HSM

o    Hardware Security Module

·         IDN

o    Internationalized Domain Name

·         IP

o    Internet Protocol

·         FIRSTCALL

o    First Call IT Services

·         PKI

o    Public Key Infrastructure

·         PMA

o    Policy Management Authority

·         RA

o    Registration Authority

·         SAN

o    Subject Alternative Name

·         TLD

o    Top Level Domain


2.1 Repositories

FIRSTCALL CP, CPS, Privacy Policy, Subscriber Agreement, and WebTrust audit documents are made publicly available in the Policy and Legal Repository, which can be found at:

2.2 Publication of certification information

Records of all FIRSTCALL root and intermediate certificates, including those that have been revoked, are available in the Certificate Repository:

FIRSTCALL certificates contain URLs to locations where certificate-related information is published, including revocation information via OCSP and/or CRLs.

2.3 Time or frequency of publication

New or updated FIRSTCALL CP, CPS, Privacy Policy, Subscriber Agreement, and WebTrust audit documents are made publicly available as soon as possible. This typically means within seven days of receipt or approval.

New or updated FIRSTCALL root and intermediate certificates are made publicly available as soon as possible. This typically means within seven days of creation.

2.4 Access controls on repositories

Read only access to the Policy and Legal Repository and certificate information is unrestricted. Write access is protected by logical and physical controls.


3.1 Naming

3.1.1 Types of names

Certificate distinguished names and subject alternative names are compliant with the CP.

3.1.2 Need for names to be meaningful

FIRSTCALL certificates include a "Subject" field which identifies the subject entity (i.e. organization or domain). The subject entity is identified using a distinguished name.

FIRSTCALL certificates include an "Issuer" field which identifies the issuing entity. The issuing entity is identified using a distinguished name.

3.1.3 Anonymity or pseudonymity of subscribers

Subscribers are not identified in DV certificates, which have subject fields identifying only domain names (not people or organizations). Relying parties should consider DV certificate subscribers to be anonymous.

3.1.4 Rules for interpreting various name forms

Distinguished names in certificates are to be interpreted using X.500 standards and ASN.1 syntax. RFC 2253 and RFC 2616 provide more information.

Certificates do not assert any specific relationship between subscribers and registrants of domain names contained in certificates.

Regarding Internationalized Domain Names, FIRSTCALL will have no objection so long as the domain is resolvable via DNS. It is the CA’s position that homoglyph spoofing should be dealt with by registrars, and Web browsers should have sensible policies for when to display the punycode versions of names.

3.1.5 Uniqueness of names

No stipulation.

3.1.6 Recognition, authentication, and role of trademarks

FIRSTCALL reserves the right to make all decisions regarding Subscriber names in certificates. Entities requesting certificates will be required to demonstrate their right to use names (e.g. demonstrate control of a domain name), but trademark rights are not verified.

While FIRSTCALL will comply with U.S. law and associated legal orders, it is FIRSTCALL's position that trademark enforcement responsibility for domain names should lie primarily with domain registrars and the legal system.

3.2 Initial identity validation

FIRSTCALL may elect not to issue any certificate at its sole discretion.

3.2.1 Method to prove possession of private key

Applicants are required to prove possession of the Private Key corresponding to the Public Key in a Certificate request, which can be done by signing the request with the Private Key.

3.2.2 Authentication of organization and domain identity

FIRSTCALL only issues Domain Validation (DV) certificates. Wildcard certificates are not supported. When a certificate request includes a list of FQDNs in a SAN list, all domains in the list are fully validated prior to issuance.

Validation for DV certificates involves demonstrating proper control over a domain. FIRSTCALL validates domain control primarily in an automated fashion via the ACME protocol. In exceptional cases control may be validated using methods similar to those employed by ACME, but performed manually.

There are three methods used for demonstrating domain control:

1.    Agreed-Upon Change to Website: Confirming the Applicant’s control over the requested FQDN by confirming the presence of agreed-upon content contained in a file or on a web page under the “/.well-known/acme-challenge/” directory on the requested FQDN that is accessible to the CA via HTTP over port 80, following redirects. (BR Section

2.    DNS Change: Confirming the Applicant’s control over the requested FQDN by confirming the presence of a random value (with at least 128 bits entropy) in a DNS TXT or CAA record for the requested FQDN prefixed with the label '_acme-challenge'. (BR Section

3.    TLS Using a Random Number: Confirming the Applicant’s control over the requested FQDN by confirming the presence of a random value (with at least 128 bits entropy) within a Certificate on the requested FQDN which is accessible to the CA via TLS over port 443. (BR Section

3.2.3 Authentication of individual identity

FIRSTCALL does not issue certificates to individuals, and thus does not authenticate individual identities.

3.2.4 Non-verified subscriber information

Non-verified Applicant information is not included in FIRSTCALL certificates.

3.2.5 Validation of authority

FIRSTCALL does not issue certificates to organizations, and thus does not validate any natural person's authority to request certificates on behalf of organizations.

Organizations have the option to specify CA issuance authority via CAA records, which FIRSTCALL respects.

3.2.6 Criteria for interoperation

FIRSTCALL discloses Cross Certificates in its Certificate Repository:

3.3 Identification and authentication for re-key requests

FIRSTCALL does not support re-key requests. Subscribers must request new certificates.

3.3.1 Identification and authentication for routine re-key

See Section 3.3 text.

3.3.2 Identification and authentication for re-key after revocation

See Section 3.3 text.

3.4 Identification and authentication for revocation request

Identification and authentication for revocation requests is performed by FIRSTCALL in compliance with Section 4.9 of this document.

Identification and authentication is not required when revocation is being requested by FIRSTCALL.


4.1 Certificate Application

4.1.1 Who can submit a certificate application

Anyone may submit an application for a certificate via the ACME protocol. Issuance will depend on proper validation and compliance with FIRSTCALL policies.

4.1.2 Enrollment process and responsibilities

The enrollment process involves the following steps, in no particular order:

·         Generating a key pair using secure methods

·         Submitting a request for a certificate containing all necessary information, including the public key

·         Agreeing to the relevant Subscriber Agreement

4.2 Certificate application processing

4.2.1 Performing identification and authentication functions

FIRSTCALL performs all identification and authentication functions in accordance with the FIRSTCALL CP. This includes validation per CPS Section 3.2.2.

FIRSTCALL checks for relevant CAA records prior to issuing certificates. The CA acts in accordance with CAA records if present. The CA’s CAA identifying domain is ‘’.

4.2.2 Approval or rejection of certificate applications

Approval requires successful completion of validation per Section 3.2.2 as well as compliance with all CA policies.

Certificates containing a new gTLD under consideration by ICANN will not be issued. The CA Server will periodically be updated with the latest version of the Public Suffix List and will consult the ICANN domains section for every requested DNS identifier. CA server will not validate or issue for DNS identifiers that do not have a Public Suffix in the ICANN domains section. The Public Suffix List is updated when new gTLDs are added, and never includes new gTLDs before they are resolvable.

FIRSTCALL maintains a list of high-risk domains and blocks issuance of certificates for those domains. Requests for removal from the high-risk domains list will be considered, but will likely require further documentation confirming control of the domain from the Applicant, or other proof as deemed necessary by FIRSTCALL management.

4.2.3 Time to process certificate applications

No stipulation.

4.3 Certificate issuance

4.3.1 CA actions during certificate issuance

Certificates issued by the Root CA require an individual authorized by FIRSTCALL to deliberately issue a direct command in order for the Root CA to perform a certificate signing operation.

The source of a certificate request is confirmed before issuance. CA processes are protected from unauthorized modification during certificate issuance. Issued certificates are stored in a database and then made available to the Subscriber.

4.3.2 Notification to subscriber by the CA of issuance of certificate

End-entity certificates are made available to Subscribers via the ACME protocol as soon after issuance as reasonably possible. Typically this happens within a few seconds.

All end-entity certificates are logged to Certificate Transparency servers as soon as reasonably possible. Typically this happens within a few seconds.

4.4 Certificate acceptance

4.4.1 Conduct constituting certificate acceptance

See FIRSTCALL CP Section 4.4.1.

4.4.2 Publication of the certificate by the CA

All root and intermediate certificates are made available publicly via the Certificate Repository.

All end-entity certificates are made available to Subscribers via the ACME protocol.

All end-entity certificates are logged to Certificate Transparency servers.

4.4.3 Notification of certificate issuance by the CA to other entities

See Section 4.4.2.

4.5 Key pair and certificate usage

4.5.1 Subscriber private key and certificate usage

Subscribers are obligated to generate Key Pairs using reasonably trustworthy systems.

Subscribers are obligated to take reasonable measures to protect their Private Keys from unauthorized use or disclosure (which constitutes compromise). Subscribers must discontinue use of any Private Keys that are known or suspected to have been compromised.

Certificates must be used in accordance with their intended purpose, which is outlined in this CPS and the associated CP. Subscribers must cease use of certificates being used outside of their intended purpose.

4.5.2 Relying party public key and certificate usage

Relying Parties must fully evaluate the context in which they are relying on certificates and the information contained in them, and decide to what extent the risk of reliance is acceptable. If the risk of relying on a certificate is determined to be unacceptable, then Relying Parties should not use the certificate or should obtain additional assurances before using the certificate.

FIRSTCALL does not warrant that any software used by Relying Parties to evaluate or otherwise handle certificates does so properly.

Relying Parties ignoring certificate expiration, revocation data provided via OCSP or CRL, or other pertinent information do so at their own risk.

4.6 Certificate renewal

Certificate renewal requests are treated as applications for new certificates.

4.7 Certificate re-key

Certificate re-key requests are treated as applications for new certificates.

4.8 Certificate modification

Certificate modification requests are treated as applications for new certificates.

4.9 Certificate revocation and suspension

Certificate revocation permanently ends the certificate's operational period prior to its stated validity period.

4.9.1 Circumstances for revocation

FIRSTCALL will follow the FIRSTCALL CP and revoke a certificate in accordance with Section and Section of the FIRSTCALL CP.

FIRSTCALL maintains a continuous (24x7x365) ability to accept and respond to revocation requests and related inquiries.

4.9.2 Who can request revocation

Anyone can revoke any certificate via the ACME API if they can sign the revocation request with the private key associated with the certificate. No other information is required in such cases. A number of ACME clients support this functionality.

Anyone can revoke any certificate via the ACME API if they can demonstrate control over all domains covered by the certificate. No other information is required in such cases. A number of ACME clients support this functionality.

Subscribers can revoke certificates belonging to their accounts via the ACME API if they can sign the revocation request with the associated account private key. No other information is required in such cases. A number of ACME clients support this.

Certificates may be administratively revoked by FIRSTCALL if it is determined that the Subscriber has failed to meet obligations under the CP, this CPS, the relevant Subscriber Agreement, or any other applicable agreement, regulation, or law. Certificates may also be administratively revoked at the discretion of FIRSTCALL management.

4.9.3 Procedure for revocation request

Revocation requests may be made at any time via the ACME API.

All other requests for revocation must be made by emailing [email protected]. FIRSTCALL will respond to such requests within 24 hours, though an investigation into the legitimacy of the request may take longer.

An investigation into whether revocation or other appropriate action is warranted will be based on at least the following criteria:

1.    The nature of the alleged problem;

2.    The number of Certificate Problem Reports received about a particular Certificate or Subscriber;

3.    The entity making the complaint; and

4.    Relevant legislation.

4.9.4 Revocation request grace period

There is no grace period for a revocation request. A revocation request must be made as soon as circumstances requiring revocation are confirmed.

4.9.5 Time within which CA must process the revocation request

Investigation into a revocation request will begin within 24 hours of receiving the request.

Once a decision has been made to revoke a certificate, revocation will be carried out within 24 hours.

4.9.6 Revocation checking requirement for relying parties

Relying Parties who cannot or choose not to check revocation status, but decide to rely on a certificate anyway, do so at their own risk.

See Section 4.5.2.

4.9.7 CRL issuance frequency (if applicable)

FIRSTCALL will issue updated CRLs for intermediate certificates with a frequency greater than or equal to that required by the FIRSTCALL CP.

FIRSTCALL does not issue CRLs for end-entity certificates.

4.9.8 Maximum latency for CRLs (if applicable)

When a CRL is requested by a Relying Party the time to receive a response will be less than ten seconds under normal operating conditions.

4.9.9 On-line revocation/status checking availability

Revocation information for all certificates is made available via OCSP. OCSP responses are available at all times (24x7x365) if possible.

4.9.10 On-line revocation checking requirements

See Section 4.9.6.

4.9.11 Other forms of revocation advertisements available

FIRSTCALL allows for OCSP stapling.

4.9.12 Special requirements re key compromise

No stipulation.

4.9.13 Circumstances for suspension

FIRSTCALL does not suspend certificates.

4.9.14 Who can request suspension

Not applicable.

4.9.15 Procedure for suspension request

Not applicable.

4.9.16 Limits on suspension period

Not applicable.

4.10 Certificate status services

4.10.1 Operational characteristics

CRL entries for intermediate certificates will remain in place until the certificates expire. FIRSTCALL does not provide CRLs for end-entity certificates.

OCSP responses will be made available for all unexpired certificates.

4.10.2 Service availability

All certificate status services are made available at all times (24x7x365) if possible.

4.10.3 Optional features

No stipulation.

4.11 End of subscription

A Subscriber's subscription ends once all of Subscriber's FIRSTCALL certificates have expired or been revoked.

Prior to the end of subscription, FIRSTCALL will send the Subscriber notice of pending Certificate expiration, in the form of a renewal notification, when 20% of the certificate’s lifetime remains, if a contact email address was provided.

4.12 Key escrow and recovery

4.12.1 Key escrow and recovery policy and practices

Not applicable.

4.12.2 Session key encapsulation and recovery policy and practices

Not applicable.


5.1 Physical controls

5.1.1 Site location and construction

FIRSTCALL Secure PKI Facilities are located in the United States, as are all copies of CA root and intermediate private keys.

FIRSTCALL maintains at least two Secure PKI Facilities at all times for the sake of redundancy.

Secure PKI Facilities are constructed so as to prevent unauthorized entry or interference.

Secure PKI Facilities are monitored at all times automated or otherwise (24x7x365) so as to prevent unauthorized entry or interference.

5.1.2 Physical access

Physical access to FIRSTCALL Secure PKI Facilities is restricted to authorized FIRSTCALL employees, vendors, and contractors, for whom access is required in order to execute their jobs. Access restrictions are strongly enforced via multi-factor authentication mechanisms.

5.1.3 Power and air conditioning

Redundant power sources are readily available at each Secure PKI Facility, and are designed to meet FIRSTCALL's operating requirements.

Air conditioning systems at each Secure PKI Facility are designed to meet FIRSTCALL's operating requirements.

5.1.4 Water exposures

FIRSTCALL Secure PKI Facilities are designed to protect FIRSTCALL infrastructure from water exposure/damage.

5.1.5 Fire prevention and protection

FIRSTCALL Secure PKI Facilities are designed to prevent fire and provide suppression if necessary.

5.1.6 Media storage

FIRSTCALL Secure PKI Facilities are designed to prevent accidental damage or unauthorized access to media.

5.1.7 Waste disposal

FIRSTCALL prohibits any media that contains or has contained sensitive data from leaving organizational control in such a state that it may still be operational, or contain recoverable data. Such media may include printed documents or digital storage devices. When media that has contained sensitive information reaches its end of life, the media is physically destroyed such that recovery is reasonably believed to be impossible.

5.1.8 Off-site backup

FIRSTCALL maintains multiple backups of private keys at multiple Secure PKI Facilities. All backups are stored on devices meeting FIPS 140 Level 3 criteria.

5.2 Procedural controls

5.2.1 Trusted roles

All persons, employees or otherwise, with the ability to materially impact the operation of FIRSTCALL PKI systems and services, or the ability to view CA confidential information, must do so while designated as serving in a Trusted Role.

Trusted Roles include, but are not limited to:

·         Management

o    May view confidential information but may not directly impact CA operations. Strong decision-making authority.

·         Security Officers

o    May view confidential information but may not directly impact CA operations. Strong decision-making authority.

·         Systems Administrators

o    May view confidential information and directly impact CA operations. Decision-making authority is limited.

·         Engineering Liaisons

o    May view confidential information but may not directly impact CA operations. No decision-making authority.

Each Trusted Role requires an appropriate level of training and legal obligation.

5.2.2 Number of persons required per task

A number of tasks, such as key generation and entering areas physically containing operating FIRSTCALL PKI systems, require at least two people to be present.

5.2.3 Identification and authentication for each role

Anyone performing work in a Trusted Role must identify and authenticate themselves before accessing FIRSTCALL PKI systems or confidential information.

5.2.4 Roles requiring separation of duties

Nobody with the ability to deploy software to FIRSTCALL PKI systems (e.g. Systems Administrators) may have the ability to commit code to core CA software. The reverse is also true.

5.3 Personnel controls

5.3.1 Qualifications, experience, and clearance requirements

FIRSTCALL management is responsible for making sure that Trusted Contributors are trustworthy and competent, which includes having proper qualifications and experience.

FIRSTCALL management ensures this with appropriate interviewing practices, training, background checks, and regular monitoring and review of Trusted Contributor job performance.

5.3.2 Background check procedures

Trusted Contributors must undergo a background check prior to performing in a trusted role. FIRSTCALL management will review the results of background checks for problematic issues prior to approving performance of a trusted role.

Background checks include, but are not limited to, criminal background and employment history.

5.3.3 Training requirements

Trusted Contributors must be trained on topics relevant to the role in which they will perform.

Training programs are developed for each role by FIRSTCALL management and Security Officers.

5.3.4 Retraining frequency and requirements

Training is repeated for each Trusted Contributor on an annual basis and re-covers all topics relevant to their trusted role.

Training is also offered whenever changes in the industry or operations require it in order for contributors to competently perform in their trusted roles.

5.3.5 Job rotation frequency and sequence

No stipulation.

5.3.6 Sanctions for unauthorized actions

Action will be taken to safeguard FIRSTCALL and its subscribers whenever FIRSTCALL Trusted Contributors, whether through negligence or malicious intent, fail to comply with FIRSTCALL policies including this CPS.

Actions taken in response to non-compliance may include termination, removal from trusted roles, or reporting to legal authorities.

Once management becomes aware of non-compliance the Trusted Contributor(s) in question will be removed from trusted roles until a review of their actions is complete.

5.3.7 Independent contractor requirements

Independent contractors who are assigned to perform Trusted Roles are subject to the duties and requirements specified for such roles in this CPS and the accompanying CP. This includes those described in Section 5.3. Potential sanctions for unauthorized activities by independent contractors are described in Section 5.3.6.

5.3.8 Documentation supplied to personnel

Trusted Contributors are provided with all documentation necessary to perform their duties. This always includes, at a minimum, a copy of the FIRSTCALL CP, CPS, and Information Security Policy.

5.4 Audit logging procedures

5.4.1 Types of events recorded

Audit logs are generated for all events related to CA security (physical and logical) and certificate issuance. Logs are automatically generated whenever possible. When it is necessary to manually log information, logs are kept on paper with written confirmation from a witness and securely stored. All audit logs, electronic or otherwise, shall be retained and made available to compliance auditors upon request.

At a minimum, each audit record includes:

·         Date and time of entry;

·         Identity of the person (or machine) making the entry; and

·         Description of the entry.

5.4.2 Frequency of processing log

No stipulation.

5.4.3 Retention period for audit log

Audit logs are retained for at least seven years and will be made available to compliance auditors upon request.

5.4.4 Protection of audit log

Audit logs, whether in production or archived, are protected using both physical and logical access controls.

5.4.5 Audit log backup procedures

FIRSTCALL makes regular backup copies of audit logs. Audit log backup copies are sent for secure offsite storage at least once per month.

5.4.6 Audit collection system (internal vs. external)

Audit data is automatically generated and reported/recorded by operating systems, CA software applications, and network devices. Systems are in place to ensure proper reporting and recording of audit data, and the failure of such systems may lead to suspension of CA services until proper audit log reporting is restored.

5.4.7 Notification to event-causing subject

No stipulation.

5.4.8 Vulnerability assessments

Audit logs are monitored by Trusted Contributors, including operations and engineering staff. Anomalies indicating attempted breaches of CA security are reported and investigated.

Automated internal and external vulnerability scans occur at least every two weeks, though more typically every week.

Extensive vulnerability assessments for FIRSTCALL infrastructure and primary CA application code are conducted at least annually by qualified third parties.

FIRSTCALL Security Officers perform a risk assessment at least annually. This risk assessment:

1.    Identifies foreseeable internal and external threats that could result in unauthorized access, disclosure, misuse, alteration, or destruction of any Certificate Data or Certificate Management Processes;

2.    Assesses the likelihood and potential damage of these threats, taking into consideration the sensitivity of the Certificate Data and Certificate Management Processes; and

3.    Assesses the sufficiency of the policies, procedures, information systems, technology, and other arrangements that the CA has in place to counter such threats.

5.5 Records archival

5.5.1 Types of records archived

FIRSTCALL archives all audit logs, the contents of which are described in Section 5.4.1. FIRSTCALL may also archive any other information deemed critical to understanding the historical performance of the CA's duties.

5.5.2 Retention period for archive

FIRSTCALL retains all documentation relating to certificate requests and the verification thereof, and all Certificates and revocation thereof, for at least seven years after any Certificate based on that documentation ceases to be valid.

5.5.3 Protection of archive

Archives are protected from unauthorized modification or destruction by strong security and environmental controls at primary and offsite storage facilities.

5.5.4 Archive backup procedures

Archives are backed up at primary CA facilities as well as at secure off-site facilities.

5.5.5 Requirements for time-stamping of records

Records are time-stamped as they are created.

Machine-created records use system time, which is synchronized automatically with third-party time sources. Machines without network access have the time set manually.

Manual records use a manually entered date and time, complete with time zone in use.

5.5.6 Archive collection system (internal or external)

No stipulation.

5.5.7 Procedures to obtain and verify archive information

No stipulation.

5.6 Key changeover

When a CA certificate is nearing expiration, a key changeover procedure is used to transition to a new CA certificate. The following steps constitute a key changeover procedure:

1.    Some time prior to CA certificate expiration, the private key associated with the expiring certificate is no longer used to sign new certificates. It is only used to sign CRLs and OCSP responses.

2.    A new key pair is generated and a new CA certificate is created containing the new key pair's public key. This new key pair is used to sign new certificates.

3.    If necessary or desired, the old private key associated with the expiring certificate may be used to cross-sign the new certificate.

5.7 Compromise and disaster recovery

5.7.1 Incident and compromise handling procedures

FIRSTCALL has created and maintains incident response procedures for a range of potential compromise and disaster situations. Such situations include, but are not limited to, natural disasters, security incidents, and equipment failure. Incident response plans are reviewed, potentially updated, and tested on at least an annual basis.

5.7.2 Computing resources, software, and/or data are corrupted

In the event that computing resources, software, and/or data are corrupted or otherwise damaged, FIRSTCALL will assess the situation, including its impact on CA integrity and security, and take appropriate action. CA operations may be suspended until mitigation is complete. Subscribers may be notified if corruption or damage has a material impact on the service provided to them.

5.7.3 Entity private key compromise procedures

In the event that a CA Private Key is compromised, or suspected to be compromised, FIRSTCALL will immediately launch a thorough investigation. Forensic evidence will be collected and secured as quickly as possible. If it cannot be determined with a high degree of certainty that the private key in question was not compromised, then the following steps may be taken in whatever order is deemed most appropriate by FIRSTCALL Security Officers:

·         Certificates relying on the private key in question will be revoked.

·         FIRSTCALL will notify root programs relying on the integrity of the key in question.

·         FIRSTCALL will notify Subscribers relying on the integrity of the key in question.

5.7.4 Business continuity capabilities after a disaster

FIRSTCALL maintains multiple geographically diverse facilities, each of which is capable of operating FIRSTCALL CA systems independently. In the event that a disaster entirely disables one facility, FIRSTCALL CA operations will fail over to another facility.

5.8 CA or RA termination

In the event that FIRSTCALL CA services are to be terminated:

·         All affected parties, including root programs and Subscribers, will be provided with notice as far in advance as reasonably possible.

·         A termination plan will be created and review by the FIRSTCALL PMA.

If a suitable successor entity exists, the following steps will be taken:

·         CA Private Keys, records, logs, and other critical documentation will be transferred to the successor organization in a secure and compliant manner.

·         Arrangements will be made for compliant continuation of CA responsibilities.

If a suitable successor entity does not exist, the following steps will be taken:

·         All certificates issued will be revoked and final CRLs will be published.

·         CA Private Keys will be destroyed.

·         CA records, logs, and other critical documentation will be transferred to a third party or government entity with appropriate legal controls in place to protect information while allowing its use in compliance with relevant policies and the law.


6.1 Key pair generation and installation

6.1.1 Key pair generation

CA private keys are generated by HSMs meeting the requirements of Section 6.2.1. This occurs during a ceremony meeting the requirements of this CPS and the accompanying CP.

Subscriber key pairs are generated and managed by Subscribers. Generation and management of Subscriber key pairs must be done in compliance with the terms of the CA Subscriber Agreement and FIRSTCALL CPS Section 9.6.3.

6.1.2 Private key delivery to subscriber

FIRSTCALL never generates or has access to Subscriber Private Keys.

6.1.3 Public key delivery to certificate issuer

Subscriber Public Keys are communicated to FIRSTCALL electronically via the ACME protocol.

6.1.4 CA public key delivery to relying parties

FIRSTCALL Public Keys are provided to Relying Parties as part of browser, operating system, or other software trusted root certificate lists.

FIRSTCALL Public Keys are also available on FIRSTCALL websites such as

6.1.5 Key sizes

FIRSTCALL CA root Private Keys are RSA keys at least 4096 bits in length.

FIRSTCALL CA intermediate Private Keys are RSA keys at least 2048 bits in length.

6.1.6 Public key parameters generation and quality checking

FIRSTCALL uses HSMs conforming to FIPS 186-4, capable of providing random number generation and on-board creation of at least 2048-bit RSA keys.

Per Section 5.3.3, NIST SP 800?89, the CA ensures that the public exponent of the RSA Keys for a DV-SSL Certificates is in the range between 216+1 and 2256-1. The moduli are an odd number, not the power of a prime, and have no factors smaller than 752.

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

See Section 7, Certificate Profiles.

6.2 Private Key Protection and Cryptographic Module Engineering Controls

6.2.1 Cryptographic module standards and controls

FIRSTCALL uses HSMs meeting FIPS 140-2 Level 3 (or higher) requirements.

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

FIRSTCALL has put into place security mechanisms which require multiple people performing in Trusted Roles in order to access CA Private Keys, both physically and logically. This is true for all copies of Private Keys, in production or backups, on-site or off-site.

6.2.3 Private key escrow

FIRSTCALL does not escrow CA Private Keys and does not provide such a service for Subscribers.

6.2.4 Private key backup

Critical FIRSTCALL Private Keys are backed up both on-site and off-site, in multiple geographic locations, under multi-person control.

6.2.5 Private key archival

FIRSTCALL does not archive private keys.

6.2.6 Private key transfer into or from a cryptographic module

FIRSTCALL CA Private Keys are generated inside HSMs and are only transferred between HSMs for redundancy or backup purposes. When transferred, keys are encrypted prior to leaving HSMs and unwrapped only inside destination HSMs. Keys never exist in plain text form outside of HSMs.

6.2.7 Private key storage on cryptographic module

FIRSTCALL CA Private Keys are stored on HSMs meeting the requirements stated in Section 6.2.1.

6.2.8 Method of activating private key

FIRSTCALL CA Private Keys are always stored on HSMs and activated using the mechanisms provided by the HSM manufacturer. Activation data and devices are protected.

6.2.9 Method of deactivating private key

FIRSTCALL CA Private Keys are always stored on HSMs and deactivated using the mechanisms provided by the HSM manufacturer.

6.2.10 Method of destroying private key

FIRSTCALL CA Private Keys are destroyed by Trusted Contributors using a FIPS 140-2 (or higher) validated zeroize method provided by the HSMs storing the keys. Physical destruction of the HSM is not required.

Subscribers are obligated to securely destroy private keys when they should no longer be used, in most cases by securely deleting all copies of private key files from storage media.

6.2.11 Cryptographic Module Rating

See Section 6.2.1.

6.3 Other aspects of key pair management

6.3.1 Public key archival

See Section 5.5.

6.3.2 Certificate operational periods and key pair usage periods

The lifetimes of FIRSTCALL Root CA certificates are specified in Section 1.1. Corresponding key pairs have the same lifetimes.

End-entity certificates issued by FIRSTCALL to Subscribers shall have a validity period less than 100 days. Subscriber key pairs may be re-used indefinitely provided that there is no suspicion or confirmation of Private Key compromise.

6.4 Activation data

6.4.1 Activation data generation and installation

Activation data used to activate CA Private Keys is generated during a key ceremony. Activation data is transferred to the person who will use it, or place it will be stored, in a secure fashion.

6.4.2 Activation data protection

Activation data is protected from unauthorized disclosure via a combination of physical and logical means.

6.4.3 Other aspects of activation data

No stipulation.

6.5 Computer security controls

6.5.1 Specific computer security technical requirements

FIRSTCALL CA infrastructure and systems are appropriately secured in order to protect CA software and data from unauthorized access or modification. Access to systems is secured via multi-factor authentication whenever possible. Security updates are applied in a timely fashion. Vulnerability scans are run regularly.

6.5.2 Computer security rating

No stipulation.

6.6 Life cycle technical controls

6.6.1 System development controls

FIRSTCALL has developed policies and procedures to effectively manage the acquisition and development of its CA systems.

FIRSTCALL CA hardware and software is dedicated solely to performing CA functions.

Vendor selection includes an evaluation of reputation in the market, ability to deliver a quality product, vulnerability history, and the likelihood of remaining viable in the future. Purchases are made in such a way that as little information about the future use of products as possible is disclosed. Physical product deliveries are received by Trusted Contributors and inspected for evidence of tampering. HSMs are shipped in tamper-evident packaging and tamper bag serial numbers are confirmed with the vendor upon reception.

FIRSTCALL maintains a CA testing environment separate from the production environment. The testing environment matches the production environment as closely as reasonably possible but does not have access to CA Private Keys used in trusted certificates. The purpose of this testing platform is to allow extensive but safe testing of software and systems that are or will be deployed to the CA production environment.

FIRSTCALL has developed and maintains appropriate change control policies and procedures to be followed any time CA systems are modified. Changes to FIRSTCALL CA systems require review by qualified Trusted Personnel who are different from the person requesting the change. Change requests are documented, as are any subsequent required reviews or approvals.

When FIRSTCALL develops software to be used in CA operations, software development policies are put into place and methodologies are followed in order to ensure software quality and integrity. This always includes a requirement for peer review of code changes. Unit testing is strongly encouraged. Code commit privileges are granted only to qualified and trusted contributors. Nobody with the ability to deploy software to FIRSTCALL PKI systems (e.g. Systems Administrators) may have the ability to commit code to core CA software. The reverse is also true.

6.6.2 Security management controls

FIRSTCALL has mechanisms in place to control and monitor security-related configuration of CA systems. Equipment and software is installed and configured using a documented change control process. Software integrity is verified upon deployment using checksums.

6.6.3 Life cycle security controls

No stipulation.

6.7 Network security controls

FIRSTCALL implements reasonable network security safeguards and controls to prevent unauthorized access to CA systems and infrastructure. FIRSTCALL's network is multi-tiered and utilizes the principle of defense in depth.

Firewalls and other critical CA systems are configured based on a necessary-traffic-only whitelisting policy whenever possible.

FIRSTCALL root CA Private Keys are stored offline in a secure manner.

6.8 Time-stamping

See Section 5.5.5.


7.1 Certificate profile

All fields are as specified in RFC5280, including fields and extensions not specifically mentioned. Extensions are not marked critical unless specifically described here as critical.

Root CA Certificate

Field or extension


Serial Number

Must be unique, with 64 bits of output from a CSPRNG

Issuer Distinguished Name

C=US, O=First Call IT Services, CN=FIRSTCALL Root CA X<n>
where n is an integer representing the instance of the Root
CA Certificate. For example, FIRSTCALL Root X1, FIRSTCALL Root X2, etc.

Subject Distinguished Name

Same as Issuer DN

Validity Period

Up to 25 years

Basic Constraints

cA=True, pathLength constraint absent

Key Usage

keyCertSign, cRLSign

Intermediate CA Certificate

Field or extension


Serial Number

Must be unique, with 64 bits of output from a CSPRNG

Issuer Distinguished Name

Derived from Issuer certificate

Subject Distinguished Name

C=US, O=First Call IT Services, CN=First Call IT Services Authority X<n>
where n is an integer representing the instance of the Subordinate CA Certificate

Validity Period

Up to 8 years

Basic Constraints

cA=True, pathLength constraint 0

Key Usage

keyCertSign, cRLSign, digitalSignature

Extended Key Usage

TLS Server Authentication, TLS Client Authentication

Certificate Policies

CAB Forum Domain Validated (
FIRSTCALL Domain Validated (
Policy Qualifier Id=CPS
Qualifier: Pointer to this CPS

Authority Information Access

Contains CA Issuers URL and OCSP URL. URLs vary based on Issuer.

CRL Distribution Points

Contains a CRL URL. URL varies based on Issuer.

DV-SSL End Entity Certificate

Field or extension


Serial Number

Must be unique, with 64 bits of output from a CSPRNG

Issuer Distinguished Name

Derived from Issuer certificate

Subject Distinguished Name

CN=one of the values from the Subject Alternative Name extension

Validity Period

90 days

Basic Constraints


Key Usage

digitalSignature, keyEncipherment

Extended Key Usage

TLS Server Authentication, TLS Client Authentication

Certificate Policies

CAB Forum Domain Validated (
FIRSTCALL Domain Validated (
CPS Qualifier: Pointer to this CPS
User Notice Qualifier: As specified in FIRSTCALL CPS section 7.1.8

Authority Information Access

Contains CA Issuers URL and OCSP URL. URLs vary based on Issuer.

Subject Public Key

RSA with modulus between 2048 and 4096, inclusive; or namedCurve P-256; or namedCurve P-384

Subject Alternative Name

A sequence of 1 to 100 dNSNames

TLS Feature

Contains status_request if requested by the subscriber in the CSR

Root OCSP Signing Certificate

Signed by a Root CA Certificate, these Certificates sign OCSP responses for Intermediate CA Certificates.

Field or extension


Serial Number

Must be unique, with 64 bits of output from a CSPRNG

Issuer Distinguished Name

C=US, O= First Call IT Services, CN= First Call IT Services CA Root X<n>

Subject Distinguished Name

C=US, O=First Call IT Services, CN= First Call IT Services CA Root OCSP X<n>

Validity Period

5 years

Basic Constraints


Key Usage


Extended Key Usage


No Check


7.1.1 Version number(s)

All certificates use X.509 version 3.

7.1.2 Certificate extensions

See section 7.1.

7.1.3 Algorithm object identifiers


Object identifier



7.1.4 Name forms

See FIRSTCALL Certificate Policy.

7.1.5 Name constraints

By policy, FIRSTCALL will not issue Certificates for IP addresses or the .mil TLD. These restrictions are not enforced by a NameConstraints extension.

7.1.6 Certificate policy object identifier

See section 7.1.

7.1.7 Usage of Policy Constraints extension

Not applicable.

7.1.8 Policy qualifiers syntax and semantics

See section 7.1.

7.1.9 Processing semantics for the critical Certificate Policies extension

Not applicable.

7.2 CRL profile

Field or Extension




Signature Algorithm



The date and time when the Certificate revocation list was issued.


ThisUpdate + 30 days


Contains: userCertificate, revocationDate, reasonCode


The serial number of this CRL in an incrementally increasing sequence of CRLs.

7.2.1 Version number(s)

See section 7.2.

7.2.2 CRL and CRL entry extensions

No stipulation.

7.3 OCSP profile

FIRSTCALL OCSP responders implement the RFC 5019 profile of RFC 6960.

7.3.1 Version number(s)

No stipulation.

7.3.2 OCSP extensions

No stipulation.


WebTrust compliance audits are intended to ensure a CA's compliance with its CP and CPS and relevant WebTrust audit criteria.

8.1 Frequency or circumstances of assessment

WebTrust compliance audit periods cover no more than one year and are scheduled by FIRSTCALL annually, every year with no gaps.

See Section 8.7 for information about the frequency of self-audits.

8.2 Identity/qualifications of assessor

FIRSTCALL's WebTrust compliance audits are 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:

1.    Independence from the subject of the audit (which is FIRSTCALL);

2.    The ability to conduct an audit that addresses the relevant criteria

3.    Employs individuals who have proficiency in examining Public Key Infrastructure technology, information security tools and techniques, information technology and security auditing, and the third-party attestation function;

4.    (For audits conducted in accordance with any one of the ETSI standards) accredited in accordance with ISO 17065 applying the requirements specified in ETSI EN 319 403;

5.    (For audits conducted in accordance with the WebTrust standard) licensed by WebTrust;

6.    Bound by law, government regulation, or professional code of ethics; and

7.    Except in the case of an Internal Government Auditing Agency, maintains Professional Liability/Errors & Omissions insurance with policy limits of at least one million US dollars in coverage

8.3 Assessor's relationship to assessed entity

FIRSTCALL's WebTrust auditors shall have no financial interest in, or other type of relationship with, FIRSTCALL, which might cause the auditors to have a bias for or against FIRSTCALL.

8.4 Topics covered by assessment

Compliance audits cover FIRSTCALL's compliance with the FIRSTCALL CP and this CPS, as well as the following WebTrust principles and criteria:

·         Principles and Criteria for Certification Authorities

·         WebTrust Principles and Criteria for Certification Authorities – SSL Baseline with Network Security

8.5 Actions taken as a result of deficiency

Noncompliance with relevant requirements will be documented by auditors (internal or external), the FIRSTCALL PMA will be informed, and the FIRSTCALL PMA will ensure that steps are taken to address the issues as quickly as reasonably possible.

8.6 Communication of results

Audit results are reported to the FIRSTCALL PMA and any other entity entitled to the results by law, regulation, or agreement. This includes a number of Web user agent (i.e. browser) root programs.

FIRSTCALL is not required to publicly disclose any audit finding that does not impact the overall audit opinion.

8.7 Self-Audits

FIRSTCALL performs a quarterly internal audit of at least 3% of issuance since the last WebTrust audit period. The sample is randomly selected. Results are saved and provided to auditors upon request.


9.1 Fees

9.1.1 Certificate issuance or renewal fees

FIRSTCALL does not charge any fees for certificate issuance or renewal. Unless issued through its website

9.1.2 Certificate access fees

No stipulation.

9.1.3 Revocation or status information access fees

FIRSTCALL does not charge any fees for certificate revocation or for checking the validity status of an issued certificate using a CRL or OSCP.

9.1.4 Fees for other services

No stipulation.

9.1.5 Refund policy

Refund if the certificate fails to issue and was charged a fee

9.2 Financial responsibility

9.2.1 Insurance coverage

No stipulation.

9.2.2 Other assets

No stipulation.

9.2.3 Insurance or warranty coverage for end-entities

No stipulation.

9.3 Confidentiality of business information

9.3.1 Scope of confidential information

No stipulation.

9.3.2 Information not within the scope of confidential information

No stipulation.

9.3.3 Responsibility to protect confidential information

FIRSTCALL employees, agents, and contractors are responsible for protecting confidential information and are bound by FIRSTCALL’s policies with respect to the treatment of confidential information or are contractually obligated to do so. Employees receive training on how to handle confidential information.

9.4 Privacy of personal information

9.4.1 Privacy plan

FIRSTCALL follows the privacy policy posted on its website ( when handling personal information.

9.4.2 Information treated as private

The privacy policy posted on FIRSTCALL’s website ( identifies information that FIRSTCALL treats as private.

9.4.3 Information not deemed private

The privacy policy posted on FIRSTCALL’s website ( identifies information that FIRSTCALL does not treat as private.

9.4.4 Responsibility to protect private information

FIRSTCALL employees and contractors are subject to policies or contractual obligations requiring them to comply with FIRSTCALL’s privacy policy ( or contractual obligations at least as protective of private information as FIRSTCALL’s privacy policy.

9.4.5 Notice and consent to use private information

FIRSTCALL follows the privacy policy posted on its website ( when using personal information.

9.4.6 Disclosure pursuant to judicial or administrative process

FIRSTCALL may disclose personal information if compelled to do so by court order or other compulsory legal process, provided that FIRSTCALL will oppose such disclosure with all legal and technical tools reasonably available to FIRSTCALL.

9.4.7 Other information disclosure circumstances

FIRSTCALL may disclose personal information under other circumstances that are described in the privacy policy posted on its website (

9.5 Intellectual property rights

FIRSTCALL and/or its business partners own the intellectual property rights in FIRSTCALL’s services, including the certificates, trademarks used in providing the services, and this CPS. Certificate and revocation information are the property of FIRSTCALL. FIRSTCALL grants permission to reproduce and distribute certificates on a non-exclusive and royalty-free basis, provided that they are reproduced and distributed in full. Private Keys and Public Keys remain the property of the Subscribers who rightfully hold them.

Notwithstanding the foregoing, third party software (including open source software) used by FIRSTCALL to provide its services is licensed, not owned, by FIRSTCALL.

9.6 Representations and warranties

9.6.1 CA representations and warranties

Except as expressly stated in this CPS or in a separate agreement with a Subscriber, FIRSTCALL does not make any representations or warranties regarding its products or services. FIRSTCALL represents and warrants, to the extent specified in this CPS, that:

1.    FIRSTCALL complies, in all material aspects, with the CP and this CPS,

2.    FIRSTCALL publishes and updates CRLs and OCSP responses on a regular basis,

3.    All certificates issued under this CPS will be verified in accordance with this CPS and meet the minimum requirements found herein and in the CAB Forum Baseline Requirements, and

4.    FIRSTCALL will maintain a repository of public information on its website.

9.6.2 RA representations and warranties

Each RA represents and warrants that:

1.    The RA’s certificate issuance and management services conform to the FIRSTCALL CP and this CPS,

2.    Information provided by the RA does not contain any false or misleading information,

3.    Translations performed by the RA are an accurate translation of the original information, and

4.    All certificates requested by the RA meet the requirements of this CPS.

FIRSTCALL’s agreement with the RA may contain additional representations and warranties.

9.6.3 Subscriber representations and warranties

1.    Each Subscriber warrants to FIRSTCALL and the public-at-large that Subscriber is the legitimate registrant of the Internet domain name that is, or is going to be, the subject of the FIRSTCALL certificate issued to Subscriber, or that Subscriber is the duly authorized agent of such registrant.

2.    Each Subscriber warrants to FIRSTCALL and the public-at-large that either (a) Subscriber did not obtain control of such domain name as the result of a seizure of such domain name, or (b) such domain name had no ongoing lawful uses at the time of such seizure.

3.    Each Subscriber warrants that all information in the FIRSTCALL certificate issued to Subscriber regarding Subscriber or its domain name is accurate, current, reliable, complete, and not misleading.

4.    Each Subscriber warrants that all information provided by Subscriber to FIRSTCALL is accurate, current, complete, reliable, complete, and not misleading.

5.    Each Subscriber warrants that Subscriber rightfully holds the Private Key corresponding to the Public Key listed in the FIRSTCALL certificate issued to Subscriber.

6.    Each Subscriber warrants that Subscriber has taken all appropriate, reasonable, and necessary steps to secure and keep Subscriber’s Private Key secret.

7.    Each Subscriber acknowledges and accepts that FIRSTCALL is entitled to revoke Subscriber’s FIRSTCALL certificates immediately if the Subscriber violates the terms of the Subscriber Agreement or if FIRSTCALL discovers that any of Subscriber’s FIRSTCALL certificates are being used to enable criminal activities such as phishing attacks, fraud, or the distribution of malware.

9.6.4 Relying party representations and warranties

Each Relying Party represents and warrants that, prior to relying on an FIRSTCALL certificate, it:

1.    Obtained sufficient knowledge on the use of digital certificates and PKI,

2.    Studied the applicable limitations on the usage of certificates and agrees to FIRSTCALL’s limitations on its liability related to the use of certificates,

3.    Has read, understands, and agrees to this CPS,

4.    Verified both the FIRSTCALL certificate and the certificates in the certificate chain using the relevant CRL or OCSP,

5.    Will not use an FIRSTCALL certificate if the certificate has expired or been revoked, and

6.    Will take all reasonable steps to minimize the risk associated with relying on a digital signature, including only relying on an FIRSTCALL certificate after considering:

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

o    The intended use of the certificate as listed in the certificate or this CPS,

o    The data listed in the certificate,

o    The economic value of the transaction or communication,

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

o    The Relying Party’s previous course of dealing with the Subscriber,

o    The Relying Party’s understanding of trade, including experience with computer-based methods of trade, and

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

Any unauthorized reliance on a certificate is at a party’s own risk.

9.6.5 Representations and warranties of other participants

No stipulation.

9.7 Disclaimers of warranties


9.8 Limitations of liability



9.9 Indemnities

9.9.1 Indemnification by FIRSTCALL

The CA does not provide any indemnification except as described in Section 9.9.1 of the Certificate Policy.

9.9.2 Indemnification by Subscribers

Each Subscriber will indemnify and hold harmless FIRSTCALL and its directors, officers, employees, agents, and affiliates from any and all liabilities, claims, demands, damages, losses, costs, and expenses, including attorneys’ fees, arising out of or related to: (i) any misrepresentation or omission of material fact by Subscriber to FIRSTCALL, irrespective of whether such misrepresentation or omission was intentional, (ii) Subscriber’s violation of the Subscriber Agreement, (iii) any compromise or unauthorized use of an FIRSTCALL certificate or corresponding Private Key, or (iv) Subscriber’s misuse of an FIRSTCALL certificate. If applicable law prohibits Subscriber from providing indemnification for another party’s negligence or acts, such restriction, or any other restriction required by law for this indemnification provision to be enforceable, shall be deemed to be part of this indemnification provision.

9.9.3 Indemnification by Relying Parties

To the extent permitted by law, each Relying Party shall indemnify FIRSTCALL, its partners, and any cross-signed entities, and their respective directors, officers, employees, agents, and contractors against any loss, damage, or expense, including reasonable attorney’s fees, related to the Relying Party’s (i) breach of any service terms applicable to the services provided by FIRSTCALL or its affiliates and used by the Relying Party, this CPS, or applicable law; (ii) unreasonable reliance on a certificate; or (iii) failure to check the certificate’s status prior to use.

9.10 Term and termination

9.10.1 Term

This CPS and any amendments to this CPS are effective when published to the FIRSTCALL online repository and remain in effect until replaced with a newer version.

9.10.2 Termination

This CPS and any amendments remain in effect until replaced with a newer version.

9.10.3 Effect of termination and survival

FIRSTCALL will communicate the conditions and effect of this CPS’s termination via the FIRSTCALL Repository. The communication will specify which provisions survive termination. At a minimum, all responsibilities related to protecting confidential information will survive termination. All Subscriber Agreements remain effective until the certificate is revoked or expired, even if this CPS terminates.

9.11 Individual notices and communications with participants

FIRSTCALL accepts notices related to this CPS at the locations specified in Section 1.5.2 of this CPS. Notices are deemed effective after the sender receives a valid and digitally signed acknowledgment of receipt from FIRSTCALL. If an acknowledgement of receipt is not received within five days, the sender must resend the notice in paper form to the street address specified in Section 1.5.2 of this CPS using either a courier service that confirms delivery or via certified or registered mail with postage prepaid and return receipt requested. FIRSTCALL may allow other forms of notice in its Subscriber Agreements.

9.12 Amendments

9.12.1 Procedure for amendment

This CPS is reviewed at least annually and may be reviewed more frequently. Amendments are made by posting an updated version of the CPS to the online repository. Controls are in place that are designed to reasonably ensure that this CPS is not amended and published without the prior authorization of the FIRSTCALL PMA.

9.12.2 Notification mechanism and period

FIRSTCALL posts CPS revisions to its Repository. FIRSTCALL does not guarantee or set a notice-and-comment period and may make changes to this CPS without notice.

9.12.3 Circumstances under which OID must be changed

The FIRSTCALL PMA is solely responsible for determining whether an amendment to the CPS requires an OID change.

9.13 Dispute resolution provisions

Any claim, suit or proceeding arising out of this CPS or any FIRSTCALL product or service must be brought in a state or federal court located in San Jose, California. FIRSTCALL may seek injunctive or other relief in any state, federal, or national court of competent jurisdiction for any actual or alleged infringement of its, its affiliates, or any third party’s intellectual property or other proprietary rights.

9.14 Governing law

The laws of the state of Florida, United States of America, govern the interpretation, construction, and enforcement of this CPS and all proceedings related to FIRSTCALL products and services, including tort claims, without regard to any conflicts of law principles. The United Nations Convention for the International Sale of Goods does not apply to this CPS.

9.15 Compliance with applicable law

This CPS is subject to all applicable laws and regulations, including United States restrictions on the export of software and cryptography products.

9.16 Miscellaneous provisions

9.16.1 Entire agreement

FIRSTCALL contractually obligates each RA to comply with this CPS and applicable industry guidelines. FIRSTCALL also requires each party using its products and services to enter into an agreement that delineates the terms associated with the product or service. If an agreement has provisions that differ from this CPS, then the agreement with that party controls, but solely with respect to that party. Third parties may not rely on or bring action to enforce such agreement.

9.16.2 Assignment

Any entities operating under this CPS may not assign their rights or obligations without the prior written consent of FIRSTCALL. Unless specified otherwise in a contract with a party, FIRSTCALL does not provide notice of assignment.

9.16.3 Severability

If any provision of this CPS is held invalid or unenforceable by a competent court or tribunal, the remainder of the CPS will remain valid and enforceable. Each provision of this CPS that provides for a limitation of liability, disclaimer of a warranty, or an exclusion of damages is severable and independent of any other provision.

9.16.4 Enforcement (attorneys' fees and waiver of rights)

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

9.16.5 Force Majeure

FIRSTCALL is not liable for any delay or failure to perform an obligation under this CPS to the extent that the delay or failure is caused by an occurrence beyond FIRSTCALL’s reasonable control. The operation of the Internet is beyond FIRSTCALL’s reasonable control.

9.17 Other provisions

No stipulation.