Direct Ecosystem Community
X.509 Certificate Policy

This certificate policy is effectively deprecated. Addtional and updated work on this CP has moved to the DirectTrust organization, and the updated document can be found at

Consensus approved on 9/23/2011. The consensus voting page can be found here. Minutes from the consensus discussion meeting can be found here.

Current Version: Version 0.9, September 23, 2011

Table of Contents

Revision History
Document Version
Document Date
Revision Details
September 23, 2011
Addressed conformance with FBCA
September 16, 2011
Updated with governance content (highlighted in blue)
August 26, 2011
Removed references to DNS
August 22, 2011
Changes based on comments received during consensus process
August 3, 2011
Add OCSP option and fix remaining CPS references
July 28, 2011
Changes based on wiki discussion threads
July 23, 2011
Changes based on 7/22/2011 workgroup call
July 13, 2011
Small changes (typos).
July 13, 2011
Initial draft.

1 Introduction

This Direct Ecosystem Community X.509 Certificate Policy (CP) follows the structure of Internet Engineering Task Force (IETF) Internet X.509 Public Key Infrastructure (PKI) Certificate Policy and Certification Practices Framework (RFC 3647).

The PKI to which this CP applies supports entities and applications involved in the exchange of electronic messages grounded in the specification of the Direct Project. The Direct Project is an initiative sponsored by the Office of the National Coordinator (ONC) for Health Information Technology to encourage adoption of secure clinical and administrative messaging within the healthcare system. Technologically the Direct Project is based on S/MIME message signatures and message encryption for the purposes of achieving privacy, authentication, message integrity, and non-repudiation.

This CP is intended to be fully consistent with the Federal Bridge Certificate Authority (FBCA) Certificate Policy. However, this CP is also intended to specify policies that further constrain the conditions under which a Direct Ecosystem conformant digital certificate may be issued. In any case where this CP found inconsistent or incompatible with the FBCA CP, the incompatibilities will be addressed at the time of policy mapping.

1.1 Overview

This Direct Ecosystem Community X.509 Certificate Policy describes the unified policy under which a conforming Certificate Authority operates. Specifically, this document defines the creation and management of X.509 version 3 public key certificates for use in applications supporting Direct Project message exchange.

1.2 Document Name and Identification

The Direct Ecosystem Community PKI defines one level of assurance assigned the following object identifier (OID):

<fill this in – under what OID root?>

Certificates issued by a CA that is in conformance with this CP may assert this level of assurance by listing this OID in the certificatePolicies X.509v3 standard extension. However, the Direct Project specification does not explicitly require utilization of policy OIDs as a mechanism of asserting trust. Rather a set of trust anchor certificates (a "bundle") are maintained by a relying party and each presented certificate must chain to a certificate within the trusted bundle.

1.3 PKI Participants

The following are roles relevant to the administration and operation of the Ecosystem PKI.

1.3.1 PKI Authorities is a healthcare-centric non-profit public/private governance entity responsible for:
  • Controlling and maintaining updates to this CP.
  • Establishing the manner in which Health Identity Providers (HIDPs – CAs and/or RAs) may publicly assert comformance to the requirements of this CP.
  • Maintain an Ecosystem Community bundle of trust anchor certificates that meet the compliance criteria specified in this CP.
  • Working with other PKI authorities to unify PKI policies and practices when deemed beneficial to secure healthcare information exchange.
  • Other responsibilities to be determined. Certification Authorities (CAs)

A certification authority (CA) in this context is an entity that signs certificate signing requests (CSRs) and issues public key X.509 certificates to Direct Subscribers. A CA must create a Certification Practices Statement that is conformant to the policies of this CP.

1.3.2 Registration Authorities (RAs)

RAs collect and verify identity information from Direct Subscribers using procedures that implement the identity validation policies set forth in this document. The RA creates CSRs for submission to a CA. RA entities must utilize identity validation policies defined in this certificate policy.

1.3.3 Subscribers

A Direct Ecosystem Subscriber is an entity whose identifying information appears as the subject in an X.509 certificate and who uses its private key and public certificate in accordance with this certificate policy.

1.3.4 Relying Parties

A Relying Party uses a Subscriber’s X.509 certificate to verify the integrity of a digitally signed message, to identify the creator of a message, or to establish confidential communications with the Subscriber. The Relying Party is responsible for deciding whether or how to check the validity of the certificate by checking the appropriate certificate status information.

1.3.5 Other Participants

No stipulation.

1.4 Certificate Usage

1.4.1 Appropriate Certificate Uses

The primary anticipated use for a Direct Ecosystem X.509 certificate is in the exchange of electronic messages grounded in the specification of the Direct Project. This includes S/MIME message signature verification and S/MIME message encryption.

1.4.2 Prohibited Certificate Uses

No stipulation.

1.5 Policy Administration

1.5.1 Organization Administering the Document is responsible for all aspects of this certificate policy.

1.5.2 Contact Person

Questions regarding this certificate policy should be directed to:

Address: <Address Here>

Phone: <Phone Here>

E-mail: <E-mail Here>

1.5.3 Person Determining Certification Practices Statement Suitability for the Policy

In order to claim conformance to this CP, the CA must submit the associated Certification Practices Statement (CPS) that states how the CA establishes the assurance required by this Certificate Policy to Inclusion in the Community Ecosystem trust anchor bundle may be dependent on a compliance audit and compliance assertions submitted by the CA in accordance with criteria established by

1.5.4 Certification Practices Statement Approval Procedures

A CA's CPS shall be submitted to the appropriate authority (see section 1.5.3) for compliance analysis with its certificate policy. If rejected, the CPS shall be revised to resolve the discrepancies and resubmitted to the appropriate authority for approval. This process shall continue until the CPS is approved.

1.6 Definitions and Acronyms

1.6.1 Acronyms

Certification Authority
Certificate Policy
Certification Practice Statement
Certificate Revocation List
Distinguished Name
Internet Engineering Task Force
Online Certificate Status Protocol
Object Identifier
Office of the National Coordinator for Health Information Technology
Public Key Infrastructure
Registration Authority
Request For Comments
Secure Multipurpose Internet Mail Extensions

1.6.2 Definitions

A digital representation of information which at least (1) identifies the Certification Authority issuing it, (2) names or identifies its Subscriber, (3) contains the Subscriber's public key, (4) identifies its operational period, and (5) is digitally signed by the Certification Authority issuing it.
Certification Authority
An authority trusted by one or more users to create and assign certificates. Also known as a Certificate Authority.
Certificate Policy
A Certificate Policy is a specialized form of administrative policy tuned
to electronic transactions performed during certificate management. A Certificate Policy addresses all aspects associated with the generation, production, distribution, accounting, compromise recovery and administration of digital certificates.
Certificate Practice Statement
A statement of the practices that a CA employs in issuing, suspending, revoking and renewing certificates and providing access to them, in accordance with specific requirements typically provided in a certificate policy.
Certificate Revocation List
A list maintained by a Certification Authority of the certificates which it has issued that are revoked prior to their stated expiration date.
Direct Project
An initiative from the Office of the National Coordinator (ONC) for Health Information Technology that created a set of standards and services that, with a policy framework, enables simple, routed, scalable, and secure message transport over the Internet between known participants.
Internet Engineering Task Force
A standards development organization responsible for the creation and maintenance of many Internet-related technical standards.
Private Key
(1) The key of a signature key pair used to create a digital signature. (2) The key of an encryption key pair that is used to decrypt confidential information. In both cases, this key must be kept secret.
Public Key
(1) The key of a signature key pair used to validate a digital signature. (2) The key of an encryption key pair that is used to encrypt confidential information. In both cases, this key is made publicly available normally in the form of a digital certificate.
Public Key Infrastructure
A set of policies, processes, server platforms, software and workstations used for the purpose of administering certificates and public-private key pairs, including the ability to issue, maintain, and revoke public key certificates.
Registration Authority
Entity responsible for identification and authentication of certificate subjects.
Relying Party
A person or Entity who has received information that includes a certificate and a digital signature verifiable with reference to a public key listed in the certificate, and is in a position to rely on them.
A Subscriber is an entity that (1) is the subject named or identified in a certificate issued to that entity, (2) holds a private key that corresponds to the public key listed in the certificate, and (3) does not itself issue certificates to another party.

2 Publication and Repository Responsibilities

2.1 Repositories and approved CAs and RAs operate repositories to support operations.

2.1.1 Repository Obligations

No stipulation.

2.2 Publication of Certification Information

2.2.1 Publication of Certificates and Certificate Status

Each approved CA should either (a) maintain a Certificate Revocation List (CRL) and expose its location in the CRL Distribution Points X.509v3 extension, or (b) maintain an equivalent Online Certificate Status Protocol (OCSP) Responder and expose its location in the Authority Information Access X.509 extension. A CA may maintain both a CRL and OCSP Responder.

2.2.2 Publication of CA Information

Each approved CA shall publish information concerning the CA necessary to support its operation and use. Information on how to obtain a copy of this certificate policy shall be provided to any party with a legitimate interest.

2.2.3 Interoperability

No stipulation

2.3 Frequency of Publication

This certificate policy, and any ensuing changes, shall be made available within 14 days of approval by

CRLs from approved CAs must expire every 30 days or less. It must be updated immediately when a new entry is added to it, or every 30 days, whichever is earlier.

2.4 Access Controls on Repositories

Approved CAs and RAs shall protect repository information not intended for public dissemination or modification.

3 Identification and Authentication

3.1 Naming

3.1.1 Types of Names

All certificates shall use non-null DN name forms for the issuer and subject names. As specified in the Direct Project Applicability Statement for Secure Health Transport, certificates tied to full (individual) Direct addresses shall contain the Direct address in the subjectAltName extended attribute as an rfc822Name and optionally in the legacy EmailAddress attribute of the Subject Distinguished Name. Certificates tied to a Direct domain (organization) shall contain the domain name in two places:

  1. The subjectAltName extension formatted as a dNSName, and
  2. The CN of the Subject DN.

3.1.2 Need for Names to be Meaningful

Names used in certificates shall uniquely identify the organization or person to which they are assigned and shall be easily understood by humans.

3.1.3 Anonymity or Pseudonymity of Subscribers

CAs shall not issue anonymous or pseudonymous certificates.

3.1.4 Rules for Interpreting Various Name Forms

No stipulation.

3.1.5 Uniqueness of Names

Approved CAs shall enforce name uniqueness within the CA's X.500 namespace of the certificate subject DN.

3.1.6 Recognition, Authentication, & Role of Trademarks

CAs will not knowingly use trademarks in names unless the subject of the certificate possesses the rights to use that name.

3.2 Initial Identity Validation

3.2.1 Method to Prove Possession of Private Key

In the case where the private key is generated by the approved RA, no proof of private key possession is required.

In the case where the Subscriber named in the certificate generates its own private key, then the Subscriber must digitally sign a known piece of data with the private key and send it to the approved CA. The approved CA will verify the signature and the known piece of data thus proving private key possession.

3.2.2 Authentication of Organization Identity

Requests for organizational certificates must include the organization name, mailing address and documentation of the existence of the organization as well as the requested domain name that will appear in the certificate (see section 3.1.1 for details).

The RA must verify that the requesting organization is a HIPAA covered entity or business associate, or is a healthcare related organization which treats protected health information with privacy and security protections that are equivalent to those required by HIPAA.

The RA must not submit a single CSR representing multiple legally distinct requesting entities to a CA. In other words, one certificate may not be used to represent multiple legally distinct entities.

The RA shall verify the organization information submitted, in addition to the authenticity of the requesting representative and the representative’s authorization to act in the name of the organization.

3.2.3 Authentication of Individual Identity Authentication of Human Subscribers

Validation of the identity of an individual is required in two cases: (1) To verify the identity of a representative of an organization requesting a Direct Ecosystem organizational certificate, and (2) To verify the identity of an individual requesting a Direct Ecosystem individual certificate.

Identity shall be established by in-person proofing before the Registration Authority, Trusted Agent or an entity certified by a State or Federal Entity as being authorized to confirm identities (e.g., notary public). Information provided shall be verified to ensure legitimacy. A trust relationship between the Trusted Agent and the applicant which is based on an in-person antecedent may suffice as meeting the in- person identity proofing requirement. Credentials required are one Federal Government-issued Picture I.D., one REAL ID Act compliant picture ID, or two Non-Federal Government I.D.s, one of which shall be a photo I.D. (e.g., Non-REAL ID Act compliant Drivers License). Any credentials presented must be unexpired. Authentication of Human Subscribers for Role-based Certificates

No stipulation. Authentication of Human Subscribers for Group Certificates

A Direct Ecosystem organizational certificate is a group certificate. Identity Verification of the organization and its representative is covered in sections 3.2.2 and Authentication of Devices

No stipulation.

3.2.4 Non-verified Subscriber Information

All Subscriber information placed in a Direct Ecosystem certificate must be verified and a certificate issued within 30 days of completion of verification.

3.2.5 Validation of Authority

The approved RA must verify the association between an organization requesting an organizational certificate and the individual representing the organization.

3.2.6 Criteria for Interoperation

To be deemed a Direct Ecosystem CA, the CA shall issue certificates according to this certificate policy or by a certificate policy that is deemed to meet equivalent criteria by

3.3 Identification and Authentication for Re-key Requests

3.3.1 Identification and Authentication for Routine Re-key

The identity of an organization and/or individual requesting a re-key of a Direct Ecosystem certificate must be established through the initial identity verification process or through proof of possession of the private key via a digital signature.

3.3.2 Identification and Authentication for Re-key after Revocation

If a Direct Ecosystem certificate is revoked, the Subscriber shall go through the initial identity verification process described in section 3.2 to obtain a new certificate.

3.4 Identification and Authentication for Revocation Request

No stipulation.

4 Certificate Life-Cycle

4.1 Application

This section specifies requirements for the initial application for a Direct Ecosystem X.509 certificate.

4.1.1 Submission of Certificate Application

The Direct Ecosystem RA creates the official certificate signing request based on input received from the Subscriber during the identity verification process.

4.1.2 Enrollment Process and Responsibilities

A Subscriber is responsible for providing accurate information about himself and his organization during identity verification. The approved Direct Ecosystem RA is responsible for archiving Subscriber data for audit purposes.

4.2 Certificate Application Processing

The approved Direct Ecosystem CA and RA are responsible for verifying that the information in a certificate signing request is accurate and reflect the information presented by the Subscriber.

4.2.1 Performing Identification and Authentication Functions

The identity verification of Subscribers shall be done by the approved Direct Ecosystem RA as specified in section 3.2.

4.2.2 Approval or Rejection of Certificate Applications

A certificate application may be rejected by an approved Direct Ecosystem CA due to missing or inaccurate information. Each approved Direct Ecosystem CA governing body retains the right to reject Direct Ecosystem certificate applications if, in its judgment, the requesting individual or organization does not have a legitimate reason to possess a Direct Ecosystem certificate.

4.2.3 Time to Process Certification Applications

All Subscriber information placed in a Direct Ecosystem certificate must be verified and a certificate issued within 30 days of completion of verification.

4.3 Issuance

4.3.1 CA Actions During Certificate Issuance

The approved Direct Ecosystem CA will ensure that the public key is bound to the correct Subscriber and generate the X.509 certificate. The approved Direct Ecosystem CA will publish the certificate as specified in section 4.4.2.

4.3.2 Notification to Subscriber of Certificate Issuance

The Subscriber must be notified via physical mail or email that his certificate has been issued.

4.4 Certificate Acceptance

4.4.1 Conduct Constituting Certificate Acceptance

Use by the Subscriber of any application using a Direct Ecosystem certificate is considered acceptance of the certificate.

4.4.2 Publication of the Certificate by the CA

The appropriate entity publishes Subscriber certificates in a directory specified in section 2.2.1.

4.4.3 Notification of Certificate Issuance by the CA to Other Entities

No stipulation.

4.5 Key Pair and Certificate Usage

4.5.1 Subscriber Private Key and Certificate Usage

Subscribers who take possession of their private key shall protect it from access by unauthorized parties.

4.5.2 Relying Party Public Key and Certificate Usage

Direct Ecosystem certificates shall conform to the policies provided by this certificate policy. Relying parties should understand these policies. The approved Direct Ecosystem CA must publish a certificate revocation list (CRL) or maintain an OCSP Responder. Relying parties should process the CRL on a regular basis and reject certificates found on it and/or respect the certificate status reflected in an OCSP response.

4.6 Certificate Renewal

Certificate renewal consists of issuing a new certificate with a new validity period and serial number while retaining all other information in the original certificate including the public key. Frequent renewal of certificates may assist in reducing the size of CRLs. After certificate renewal, the old certificate may or may not be revoked, but must not be further re-keyed, renewed, or modified.

4.6.1 Circumstance for Certificate Renewal

A certificate may be renewed if the public key has not reached the end of its validity period, the associated private key has not been compromised, and the Subscriber name and attributes are unchanged. Certificates may also be renewed if the approved Direct Ecosystem CA re-keys.

4.6.2 Who May Request Renewal

The approved Direct Ecosystem CA may request renewal of its own certificate. For Subscriber certificates, the Subscriber himself or the approved Direct Ecosystem RA may request renewal.

4.6.3 Processing Certificate Renewal Requests

The approved Direct Ecosystem CA shall approve or reject Subscriber certificate renewal requests. Identity verification of the Subscriber shall be equivalent to the initial identity verification process or executed via proof of possession of the private key through a digital signature.

4.6.4 Notification of New Certificate Issuance to Subscriber

The Subscriber is notified via physical mail or email that his certificate has been issued if such notification is relevant to the Subscriber’s usage of the certificate.

4.6.5 Conduct Constituting Acceptance of a Renewal Certificate

Use by the Subscriber of any application using a Direct Ecosystem certificate is considered acceptance of the certificate.

4.6.6 Publication of the Renewal Certificate by the CA

The approved Direct Ecosystem CA publishes Subscriber certificates in a directory specified in section 2.2.1.

4.6.7 Notification of Certificate Issuance by the CA to Other Entities

No stipulation.

4.7 Certificate Re-Key

Re-keying a certificate consists of creating new certificates with a different public key (and serial number) while retaining the remaining contents of the old certificate that describe the subject. The new certificate may be assigned a different validity period, key identifiers, specify a different CRL distribution point or OCSP Responder location, and/or be signed with a different key. Re-key of a certificate does not require a change to the subjectName and does not violate the requirement for name uniqueness.

After certificate re-key, the old certificate may or may not be revoked, but must not be further re-keyed, renewed, or modified.

4.7.1 Circumstance for Certificate Re-Key

A certificate shall be re-keyed when it can no longer be renewed as described in section 4.6.1. A revoked certificate shall not be re-keyed.

4.7.2 Who May Request Certification of a New Public Key

An approved Direct Ecosystem RA or the Subscriber may request the re-key of a Subscriber certificate.

4.7.3 Processing Certificate Re-Keying Requests

The approved Direct Ecosystem CA shall approve or reject Subscriber certificate re-keying requests. Identity verification of the Subscriber shall be equivalent to the initial identity verification.

4.7.4 Notification of New Certificate Issuance to Subscriber

See section 4.3.2.

4.7.5 Conduct Constituting Acceptance of a Re-Keyed Certificate

See section 4.4.1.

4.7.6 Publication of the Re-keyed Certificate by the CA

See section 4.4.2.

4.7.7 Notification of Certificate Issuance by the CA to Other Entities

See section 4.4.3.

4.8 Modification

Certificate modification consists of creating a new certificate with subject information (e.g., a name or email address) that differs from the old certificate. The new certificate may have the same or different subject public key.

After certificate modification, the old certificate may or may not be revoked, but must not be further re-keyed, renewed, or modified.

4.8.1 Circumstance for Certificate Modification

A certificate may be modified if some of the information in the certificate has changed.

4.8.2 Who May Request Certificate Modification

The Subscriber or the approved Direct Ecosystem RA may request modification of a Subscriber certificate.

4.8.3 Processing Certificate Modification Requests

Identity verification for a certificate modification request shall be accomplished using one of the following processes:

  • Initial identity verification process as described in Section 3.2, or
  • Identity verification for re-key as described in Section 3.3, except the old key can be used as the new key also.

4.8.4 Notification of New Certificate Issuance to Subscriber

See section 4.3.2.

4.8.5 Conduct Constituting Acceptance of Modified Certificate

See section 4.4.1.

4.8.6 Publication of the Modified Certificate by the CA

See section 4.4.2.

4.8.7 Notification of Certificate Issuance by the CA to Other Entities

See section 4.4.3.

4.9 Certificate Revocation and Suspension

4.9.1 Circumstances for Revocation

A certificate shall be revoked when the binding between the subject and the subject’s public key defined within a certificate is no longer considered valid. Examples of circumstances that invalidate the binding are:

  • identifying information or affiliation components of any names in the certificate become invalid,
  • the Subscriber can be shown to have violated the stipulations of its Subscriber agreement,
  • the private key is suspected of compromise, and
  • the Subscriber asks for his/her certificate to be revoked.

Whenever any of the above circumstances occur, the associated certificate shall be revoked and placed on the certificate revocation list (CRL) and/or have its revoked status reflected in OCSP responses.

4.9.2 Who Can Request Revocation

The CA/RA may request revocation of a certificate, or the the issuing CA may entertain requests from a Subscriber to revoke a certificate.

4.9.3 Procedure for Revocation Request

Any request for certificate revocation shall identify the certificate to be revoked by serial number and explain the reason for revocation. An approved Direct Ecosystem RA and CA shall ensure that the certificate revocation request is not malicious and will verify that the reason for revocation is valid.

If the reason for revocation is valid, the approved Direct Ecosystem CA will place the certificate’s serial number and any other required information on its certificate revocation list (CRL) and/or have its revoked status reflected in OCSP responses.

4.9.4 Revocation Request Grace Period

There is no grace period for revocation under this policy. Subscribers and authorized PKI entities shall request the revocation of a certificate as soon as the need for revocation comes to their attention.

4.9.5 Time Within Which CA Must Process the Revocation Request

An approved Direct Ecosystem CA must process all revocation requests within 8 hours of receipt. CRL issuance frequency is addressed in Section 4.9.7.

4.9.6 Revocation Checking Requirements for Relying Parties

The matter of how often new revocation data should be obtained is a determination to be made by the Relying Party.

4.9.7 CRL Issuance Frequency

A Direct Ecosystem CRL must be issued and posted to the repository listed in section 2.2.1 every 30 days when there are no changes or updates to be made to ensure timeliness of information. A CRL may be issued more frequently than every 30 days if new entries are made to the CRL. The approved Direct Ecosystem CA must ensure that superseded CRLs are removed from the repository upon posting of the latest CRL.

4.9.8 Maximum Latency of CRLs

CRLs shall be posted upon generation but within no more than four hours after generation. Furthermore, a new CRL shall be published no later than the time specified in the nextUpdate field of the most recently published CRL.

4.9.9 On-Line Revocation/Status Checking Availability

A CA may deploy an Online Certificate Status Protocol (OCSP) responder.

4.9.10 On-Line Revocation Checking Requirements

The timeliness of OCSP responses shall be as specified in section 4.9.8 of this CP.

4.9.11 Other Forms of Revocation Advertisements Available

No other form of revocation advertisement is required.

4.9.12 Special Requirements Related to Key Compromise

No stipulation.

4.9.13 Circumstances for Suspension

Certificate suspension occurs by marking a certificate as revoked with a reason code of “On Hold.” These certificates shall be placed on the next CRL and shall remain on the CRL until the certificate is restored or the certificate expires. A certificate is restored when the CA reinstates it. Certificates that are marked as revoked with a reason code other than “On Hold” shall not be restored.

Direct Ecosystem CAs are not required to support suspended certificates.

4.9.14 Who Can Requests Suspension

No stipulation.

4.9.15 Procedure for Suspension Request

No stipulation.

4.9.16 Limits on Suspension Period

No stipulation.

4.10 Certificate Status Services

Direct Ecosystem CAs may support certificate status services beyond a CRL (OCSP).

4.10.1 Operational Characteristics

No stipulation.

4.10.2 Service Availability

No stipulation.

4.10.3 Optional Features

No stipulation.

4.11 End of Subscription

Certificates that have expired prior to or upon end of subscription are not required to be revoked. A Subscriber with an unexpired certificate who is no longer using the certificate in an approved manner (e.g., for Direct Project secure communications) should have his certificate revoked.

4.12 Key Escrow and Recovery

No stipulation.

4.12.1 Key Escrow and Recovery Policy and Practices

No stipulation.

4.12.2 Session Key Encapsulation and Recovery Policy and Practices

No stipulation.

5 Facility Management and Operations Controls

5.1 Physical Controls

Direct Ecosystem CA and RA equipment shall be protected from unauthorized access at all times.

5.1.1 Site Location and Construction

The location and construction of the facility housing the CA/RA equipment shall be consistent with facilities used to house sensitive information. The location and construction shall provide robust protection against unauthorized access to the CA/RA equipment and records.

5.1.2 Physical Access

The CA/RA equipment shall always be protected from unauthorized access with appropriate access control. Entry shall be restricted to trained CA Officers only.

5.1.3 Power and Air Conditioning

The CA/RA equipment shall possess a UPS to allow for a graceful shutdown in the event of power failure. Should excessive heat build-up occur in the physical surroundings of the CA equipment, procedures shall be in place to prevent equipment damage.

5.1.4 Water Exposures

CA/RA equipment shall be installed such that it is not in danger of exposure to water other than water from fire prevention and protections systems.

5.1.5 Fire Prevention and Protection

No stipulation.

5.1.6 Media Storage

CA/RA media shall be stored so as to protect it from accidental damage (such as water, fire, electromagnetic, etc.). Media that contains audit, archive, or backup information shall be duplicated and stored in a location separate from the CA/RA equipment and shall be protected from unauthorized access.

5.1.7 Waste Disposal

Sensitive media and documentation that are no longer needed for operations shall be destroyed in a secure manner. For example, sensitive paper documentation shall be shredded, burned, or otherwise rendered unrecoverable.

5.1.8 Off-Site Backup

System backups, sufficient to recover from system failure, shall be made on a periodic schedule. At least one backup copy shall be stored at an offsite location separate from the CA/RA equipment. The backup shall be stored at a site with physical and procedural controls commensurate to that of the operational CA/RA system.

5.2 Procedural Controls

5.2.1 Trusted Roles

A trusted role is one whose incumbent performs functions that can introduce security problems if not carried out properly, whether accidentally or maliciously. The people selected to fill these roles must be extraordinarily responsible or the integrity of the CA is weakened. The functions performed in these roles form the basis of trust for all uses of the CA. Two approaches should be taken to increase the likelihood that these roles can be successfully carried out. The first ensures that the person filling the role is trustworthy and properly trained. The second distributes the functions among more than one person, so that any malicious activity would require collusion.

The requirements of this policy are defined in terms of four roles.

  1. Administrator – authorized to install, configure, and maintain the CA; establish and maintain user accounts; configure profiles and audit parameters; and generate component keys.
  2. Officer – authorized to request or approve certificates or certificate revocations.
  3. Auditor – authorized to maintain audit logs.
  4. Operator – authorized to perform system backup and recovery.

Some roles may be combined. The following subsections provide a detailed description of the responsibilities for each role. Administrator

The administrator role is responsible for:

  • Installation, configuration, and maintenance of the CA,
  • Establishing and maintaining CA system accounts,
  • Configuring certificate profiles or templates and audit parameters, and
  • Generating and backing up CA keys.

Administrators do not issue certificates to Subscribers. Officer

The officer role is responsible for issuing certificates, that is:

  • Registering new Subscribers and requesting the issuance of certificates,
  • Verifying the identity of Subscribers and accuracy of information included in certificates,
  • Approving and executing the issuance of certificates, and
  • Requesting, approving and executing the revocation of certificates. Auditor

The auditor role is responsible for:

  • Reviewing, maintaining, and archiving audit logs
  • Performing or overseeing internal compliance audits to ensure that the CA is operating in accordance with its Certification Practice Statement (CPS). Operator

The operator role is responsible for the routine operation of the CA equipment and operations such as system backups and recovery or changing recording media.

5.2.2 Number of Persons Required Per Task

At least two people are trained for each task but only one is required to execute each task.

5.2.3 Identification and Authentication for Each Role

A person occupying a trusted role shall authenticate himself to the CA system.

5.2.4 Separation of Roles

Any individual may assume the Operator role. A person assuming the Auditor role may not assume the Officer or Administrator role.

5.3 Personnel Controls

5.3.1 Background, Qualifications, Experience, and Security Clearance Requirements

All persons filling trusted roles shall be selected on the basis of loyalty, trustworthiness, and integrity. All trusted roles are required to be held by persons who are legally eligible to work in the United States.

5.3.2 Background Check Procedures

No stipulation.

5.3.3 Training Requirements

Persons in a Trusted Role shall receive comprehensive training in all aspects of the role they perform. All persons shall have a reasonable understanding of PKI principles and operations.

5.3.4 Retraining Frequency and Requirements

Individuals responsible for Trusted Roles shall be aware of changes in CA operation. Any significant change to the operations shall have a training (awareness) plan, and the execution of such plan shall be documented. Documentation shall be maintained identifying all personnel who received training and the level of training completed.

5.3.5 Job Rotation Frequency and Sequence

No stipulation.

5.3.6 Sanctions for Unauthorized Actions

The CA governance entity shall take appropriate administrative and disciplinary actions against personnel who violate this policy.

5.3.7 Independent Contractor Requirements

Contractor personnel employed to perform functions pertaining to the CA shall meet the personnel requirements set forth in this CP.

5.3.8 Documentation Supplied to Personnel

Documentation sufficient to define duties and procedures for each role shall be provided to the personnel filling that role.

5.4 Audit Logging Procedures

Audit log files shall be generated for all events relating to the security of the CA. All security audit logs, both electronic and non-electronic, shall be retained and made available during compliance audits.

5.4.1 Types of Events Recorded

Security events included in audit logs of the CA are:

  • Authentication to the CA equipment,
  • Generation of PKI materials including private keys, certificate signing requests, and certificates.

5.4.2 Frequency of Processing Log

Audit logs are reviewed and monitored regularly to ensure that any irregularities are identified and handled properly.

5.4.3 Retention Period for Audit Logs

Security audit log data shall be available on the CA equipment for a minimum of two months.

5.4.4 Protection of Audit Logs

Only authorized personnel (CA officers) shall have access to the logs, and only authorized personnel shall archive the logs. CA configuration and processes shall enforce these requirements.

5.4.5 Audit Log Backup Procedures

Security audit data should be backed up at least monthly and stored off-site in a secure location.

5.4.6 Audit Collection System (internal vs. external)

All security audit processes shall be invoked at CA startup and cease only at shutdown. Should it become apparent that an automated security audit system has failed, the CA shall cease all operation except for revocation processing until the security audit capability can be restored.

5.4.7 Notification to Event-Causing Subject

There is no requirement to notify a subject that an event was audited. Real-time alerts are neither required nor prohibited by this policy.

5.4.8 Vulnerability Assessments

The CA shall be subjected to the same vulnerability assessments as other critical systems.

5.5 Records Archival

5.5.1 Types of Events Archived

CA archive records shall be sufficiently detailed as to verify that the CA was properly operated as well as verify the validity of any certificate throughout its validity period. At a minimum, the following data shall be archived:

  • CP, CPS
  • Certificate Requests
  • Issued certificates
  • Authentication logs

5.5.2 Retention Period for Archive

CA archives shall be kept for a minimum of three years.

5.5.3 Protection of Archive

Only authorized individuals shall be permitted to add to or delete from the archive. Archive media shall be stored in a separate, safe, secure storage facility.

5.5.4 Archive Backup Procedures

No stipulation.

5.5.5 Requirements for Time-Stamping of Records

CA archive records shall be automatically time-stamped as they are created.

5.5.6 Archive Collection System (Internal vs. External)

No stipulation.

5.5.7 Procedures to Obtain & Verify Archive Information

No stipulation.

5.6 Key Changeover

The CA will not issue Subscriber certificates that extend beyond the expiration date of its own CA certificates and public keys, and the CA certificate validity period must extend one Subscriber certificate validity period past the last use of the CA private key. To minimize risk to the PKI through compromise of a CA’s key, the private signing key will be changed more frequently, and only the new key will be used for certificate signing purposes from that time. The older, but still valid, certificate will be available to verify old signatures until all of the Subscriber certificates signed under it have also expired. If the old private key is used to sign CRLs that contain certificates signed with that key, then the old key must be retained and protected.

The CA self-signed root certificate shall be valid for no more than 20 years.

5.7 Compromise and Disaster Recovery

5.7.1 Incident and Compromise Handling Procedures

If a hacking attempt or other form of potential compromise of a CA becomes known, it shall be investigated in order to determine the nature and the degree of damage. If the CA key is suspected of compromise, the procedures outlined in Section 5.7.3 shall be followed. Otherwise the scope of potential damage shall be assessed in order to determine if the CA needs to be rebuilt, only some certificates need to be revoked, and/or the CA key needs to be declared compromised.

5.7.2 Computing Resources, Software, and/Or Data Are Corrupted

The CA shall maintain backup copies of system, databases, and private keys in order to rebuild the CA capability in case of software and/or data corruption. Prior to resuming operations, the CA shall ensure that the system’s integrity has been restored.

5.7.3 Entity Private Key Compromise Procedures

If the CA key is compromised, the trusted self-signed certificate must be removed from each Relying Party application, and a new one distributed via secure out-of-band mechanisms.

5.7.4 Business Continuity Capabilities after a Disaster

In the case of a disaster in which the CA equipment is damaged and inoperative, the CA operations shall be reestablished as quickly as possible, giving priority to the ability to revoke Subscriber's certificates. If the CA cannot reestablish revocation capabilities prior to the next update field in the latest CRL issued by the CA, then the CA governing body shall decide whether to declare the CA private signing key as compromised, and reestablish the CA keys and certificates and all Subscriber certificates, or allow additional time for reestablishment of the CA’s revocation capability.

In the case of a disaster whereby the CA installation is physically damaged and all copies of the CA signature key are destroyed as a result, the CA will be completely rebuilt by reestablishing the CA equipment and generating new private and public keys. Finally, all Subscriber certificates shall be re-issued. In such events, any Relying Parties who continue to use certificates signed with the destroyed private key do so at their own risk and the risk of others to whom they forward data.

5.8 CA and RA Termination

In the event of CA termination, certificates signed by the CA shall be revoked.

6 Technical Security Controls

6.1 Key Pair Generation and Installation

6.1.1 Key Pair Generation CA Key Pair Generation

The CA cryptographic keying material used to sign certificates or CRLs shall be generated on physical hardware that is well protected. Subscriber Key Pair Generation

The CA cryptographic keying material generated for Subscriber certificates shall be created on physical hardware that is well protected.

6.1.2 Private Key Delivery to Subscriber

No stipulation.

6.1.3 Public Key Delivery to Certificate Issuer

No stipulation.

6.1.4 CA Public Key Delivery to Relying Parties

A new CA root public key will be delivered within a self-signed certificate using an out-of-band medium trusted by the relying party.

6.1.5 Key Sizes

An approved Direct Ecosystem CA shall utilize the SHA-256 algorithm for certificate signatures.

All keys shall be at least 2048 bit (RSA).

6.1.6 Public Key Parameters Generation and Quality Checking

Public key parameters prescribed in the Digital Signature Standard (DSS) shall be generated in accordance with FIPS 186-2 or equivalent.

Parameter quality checking (including primality testing for prime numbers) shall be performed in accordance with FIPS 186.

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

Direct Ecosystem Subscriber public keys that are bound into certificates shall be certified for use in signing and encryption of S/MIME packages as required by the Direct Project specifications. Specifically, Subscriber certificates shall assert the following key usage bits:

  • digitalSignature
  • keyEncipherment
  • nonRepudiation

Subscriber certificates shall also assert an extended key usage bit of emailProtection and a Basic Constraint of CA:FALSE.

An approved Direct Ecosystem CA root certificate shall assert the following key usage bits:

  • cRLSign
  • keyCertSign

The CA root certificate shall also assert a Basic Constraint of CA:TRUE.

6.2 Private Key Protection and Cryptographic Module Engineering Controls

6.2.1 Cryptographic Module Standards and Controls

No stipulation.

6.2.2 Private Key Multi-Person Control

No stipulation.

6.2.3 Private Key Escrow

No private keys (CA or Subscriber) are required to be escrowed.

6.2.4 Private Key Backup

The CA root private signature key shall be backed up to a secure offsite location to facilitate disaster recovery.

Subscriber private keys shall be backed up to a secure offsite location to facilitate disaster recovery.

6.2.5 Private Key Archival

No stipulation.

6.2.6 Private Key Transfer into or from a Cryptographic Module

No stipulation.

6.2.7 Private Key Storage on Cryptographic Module

No stipulation.

6.2.8 Method of Activating Private Keys

No stipulation.

6.2.9 Methods of Deactivating Private Keys

No stipulation.

6.2.10 Method of Destroying Private Keys

Individuals in trusted roles shall destroy private signature keys when they are no longer needed. Subscriber private signature keys shall be destroyed when they are no longer needed, or when the certificates to which they correspond expire or are revoked.

6.2.11 Cryptographic Module Rating

No stipulation.

6.3 Other Aspects of Key Management

6.3.1 Public Key Archival

Public keys are archived as part of the certificate archival process.

6.3.2 Certificate Operational Periods/Key Usage Periods

A CA root private key shall be used for a maximum of 20 years. A CA root certificate shall expire after a maximum of 20 years.

Subscriber private keys shall be used for a maximum of 10 years. Subscriber public certificates shall expire after one year.

6.4 Activation Data

6.4.1 Activation Data Generation and Installation

No stipulation.

6.4.2 Activation Data Protection

No stipulation.

6.4.3 Other Aspects of Activation Data

No stipulation.

6.5 Computer Security Controls

6.5.1 Specific Computer Security Technical Requirements

For an approved Direct Ecosystem CA, the computer security functions listed below are required. These functions may be provided by the operating system, or through a combination of operating system, software, and physical safeguards:

  • Authenticated logins
  • Security audit controls
  • Access control to qualified and trained individuals

6.5.2 Computer Security Rating

No stipulation.

6.6 Life-Cycle Security Controls

6.6.1 System Development Controls

CA software shall be developed in a controlled development environment with modern source code control. CA hardware and software shall be dedicated to performing the CA tasks. CA hardware and software containing private keys shall be well protected. Hardware and software updates shall be tested and installed in a professional and controlled manner.

6.6.2 Security Management Controls

The configuration of a CA system as well as any modifications and upgrades shall be documented and controlled. A formal configuration management methodology shall be used for installation and ongoing maintenance of the CA system.

6.6.3 Life Cycle Security Ratings

No stipulation.

6.7 Network Security Controls

Information to be transferred from the CA shall be done through dedicated removable media or secure networks.

The RA shall employ appropriate security measures to ensure it is guarded against denial of service and intrusion attacks. Such measures include the use of guards, firewalls and filtering routers.

6.8 Time Stamping

All system clock time for the CA system shall be derived from a trusted time service. Asserted times shall be accurate to within three minutes.

7 Certificate, CRL, and OCSP Profiles Format

7.1 Certificate Profile

7.1.1 Version Numbers

Approved Direct Ecosystem CAs shall issue X.509 v3 certificates, which means the version field should contain the integer 2.

7.1.2 Certificate Extensions

A CA shall use standard certificate extensions that are compliant with IETF RFC 3280.

The Key Usage, Extended Key Usage, and Basic Constraints extensions shall be populated as specified in section 6.1.7 of this certificate policy.

The CRL Distribution Points extension may be populated with a CRL URL as specified in section 2.2.1 of this certificate policy.

The Authority Information Access extension may be populated with an OCSP Responder location as specified in section 2.2.1 of this certificate policy.

The Subject Alternative Name extension shall be populated as specified in section 3.1.1 of this certificate policy.

The Certificate Policies extension shall be populated as defined in section 7.1.6 of this certificate policy.

7.1.3 Algorithm Object Identifiers

Certificates signed by an approved Direct Ecosystem CA shall use the sha-256 signature algorithm and identify it using the following OID:

sha256WithRSAEncryption: {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 11}

Certificates issued by an approved Direct Ecosystem CA shall use the following OID for identifying the subject public key algorithm:

rsaEncryption: {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1}

7.1.4 Name Forms

See section 3.1.1 of this Certificate Policy.

7.1.5 Name Constraints

No stipulation.

7.1.6 Certificate Policy Object Identifier

Certificates shall assert the policy OID defined in section 1.2 of this certificate policy.

7.1.7 Usage of Policy Constraints Extension

No stipulation.

7.1.8 Policy Qualifiers Syntax and Semantics

Certificates issued by an approved Direct Ecosystem CA shall contain no policy qualifiers.

7.1.9 Processing Semantics for the Critical Certificate Policy Extension

This policy does not require the certificatePolicies extension to be critical. Relying Parties whose client software does not process this extension risk using certificates inappropriately.

7.2 CRL Profile

7.2.1 Version Numbers

An approved Direct Ecosystem CA shall issue X.509 version 2 CRLs, which means the version field should contain the integer 1.

7.2.2 CRL and CRL Entry Extensions

An approved Direct Ecosystem CA shall conform to the CRL and CRL Extensions profile defined in IETF RFC 3280.

An approved Direct Ecosystem CA shall sign the CRL using the sha-256 signature algorithm and identify it using the following OID:

sha256WithRSAEncryption: {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 11}

The CRL shall contain a CRL Reason Code entry extension for each entry.

7.3 OCSP Profile

An approved Direct Ecosystem CA may deploy an OCSP responder. No stipulation is made beyond this assertion.

8 Compliance Audits and Other Assessments shall have a compliance audit review procedure in place to ensure that the requirements of this CP are being implemented and enforced. CAs and RAs shall have a compliance audit mechanism in place to ensure that the requirements of their CP/CPS are being implemented and enforced. This specification does not impose a requirement for any particular assessment methodology.

8.1 Frequency and Circumstances of Assessment

The audit occurs every two years.

8.2 Identity/Qualifications of Assessor

The auditor must demonstrate competence in the field of compliance audits. The CA compliance auditor must be thoroughly familiar with the requirements which the CA imposes on the issuance and management of its certificates.

8.3 Assessor’s Relationship to Assessed Entity may establish a compliance audit process that relies on legally binding self-attestation by the CA/RA.

As an alternative to using the a compliance audit process, the CA may choose to use a compliance auditor that shall be a private firm, that is independent from the entity being audited, or that shall be sufficiently organizationally separated from that entity to provide an unbiased, independent evaluation.

8.4 Topics Covered by Assessment

No stipulation.

8.5 Actions Taken as a Result of Deficiency

If finds a discrepancy between the CA/RA operation and the stipulation of its practices and such discrepancy can not be resolved in a satisfactory manner, may withhold the right of the CA/RA to assert conformance to this CP and not include the CA certificate in the Direct Ecosystem trust anchor bundle.

8.6 Communication of Results

Upon review and approval of an Audit Compliance Report submitted by a CA, will issue a letter authorizing the CA to claim conformance to this CP and, if it has been requested by the CA, include the CA root certificate in the Direct Ecosystem trust bundle.

9 Other Business and Legal Matters

9.1 Fees

9.1.1 Certificate Issuance/Renewal Fees

No stipulation.

9.1.2 Certificate Access Fees

No stipulation.

9.1.3 Revocation or Status Information Access Fee

No stipulation.

9.1.4 Fees for other Services

No stipulation.

9.1.5 Refund Policy

No stipulation.

9.2 Financial Responsibility

9.2.1 Insurance Coverage

No stipulation.

9.2.2 Other Assets

No stipulation.

9.2.3 Insurance/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

No stipulation.

9.4 Privacy of Personal Information

9.4.1 Privacy Plan

All identifying information for a Subscriber shall be protected from unauthorized disclosure.

9.4.2 Information Treated as Private

Information deemed as private shall be defined as such in agreements between the CA and its Subscribers.

9.4.3 Information Not Deemed Private

Information included in certificates is not deemed private.

9.4.4 Responsibility to Protect Private Information

A Direct Ecosystem CA shall store private information securely.

9.4.5 Notice and Consent to Use Private Information

A Direct Ecosystem CA shall use private information as dictated by the agreements with its Subscribers.

9.4.6 Disclosure Pursuant to Judicial/Administrative Process

A Direct Ecosystem CA shall not disclose private information unless allowed by agreements with its Subscribers or unless required to by law.

9.4.7 Other Information Disclosure Circumstances

No stipulation.

9.5 Intellectual Property Rights and Direct Ecosystem CAs will not knowingly violate the intellectual property rights held by others.

9.6 Representations and Warranties

9.6.1 CA Representations and Warranties

No stipulation.

9.6.2 RA Representations and Warranties

No stipulation.

9.6.3 Subscriber Representations and Warranties

No stipulation.

9.6.4 Relying Parties Representations and Warranties

A relying party shall use a Direct Ecosystem certificate for the purpose for which it was intended and check each certificate for validity.

9.6.5 Representations and Warranties of Affiliated Organizations

No stipulation.

9.6.6 Representations and Warranties of Other Participants

No stipulation.

9.7 Disclaimers of Warranties

No stipulation.

9.8 Limitations of Liabilities

No stipulation.

9.9 Indemnities

No stipulation.

9.10 Term and Termination

9.10.1 Term

This certificate policy becomes effective when approved by This certificate policy has no specified term.

9.10.2 Termination

Termination of this certificate policy is at the discretion of

9.10.3 Effect of Termination and Survival

The requirements of this certificate policy remain in effect through the end of the archive period of the last certificate issued.

9.11 Individual Notices and Communications with Participants

No stipulation.

9.12 Amendments

9.12.1 Procedure for Amendment must review this certificate policy yearly and make and communicate any changes.

9.12.2 Notification Mechanism and Period

No stipulation.

9.12.3 Circumstances Under Which OID Must be Changed

No stipulation.

9.13 Dispute Resolution Provisions shall resolve any disputes related to this certificate policy.

9.14 Governing Law

The laws of the United States of America shall govern this Policy.

9.15 Compliance with Applicable Law

All PKI participants shall comply with applicable laws.

9.16 Miscellaneous Provisions

9.16.1 Entire Agreement

No stipulation.

9.16.2 Assignment

No stipulation.

9.16.3 Severability

Should it be determined that one section of this certificate policy is incorrect or invalid, the other sections of this certificate policy shall remain in effect until the certificate policy is updated.

9.16.4 Enforcement (Attorney Fees/Waiver of Rights)

No stipulation.

9.16.5 Force Majeure

No stipulation.

9.17 Other Provisions

No stipulation.