Direct Ecosystem Community X
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
[1].
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
| Document Version |
Document Date |
Revision Details |
| 0.9 |
September 23, 2011 |
Addressed conformance with FBCA |
| 0.8 |
September 16, 2011 |
Updated with DirectTrust.org governance content (highlighted in blue) |
| 0.7 |
August 26, 2011 |
Removed references to DNS |
| 0.6 |
August 22, 2011 |
Changes based on comments received during consensus process |
| 0.5 |
August 3, 2011 |
Add OCSP option and fix remaining CPS references |
| 0.4 |
July 28, 2011 |
Changes based on wiki discussion threads |
| 0.3 |
July 23, 2011 |
Changes based on 7/22/2011 workgroup call |
| 0.2 |
July 13, 2011 |
Small changes (typos). |
| 0.1 |
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
1.3.1.1 DirectTrust.org
DirectTrust.org 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.
1.3.1.2 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
DirectTrust.org is responsible for all aspects of this certificate policy.
1.5.2 Contact Person
Questions regarding this certificate policy should be directed to:
DirectTrust.org
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 DirectTrust.org. 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 DirectTrust.org.
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
| Acronym |
Meaning |
| CA |
Certification Authority |
| CP |
Certificate Policy |
| CPS |
Certification Practice Statement |
| CRL |
Certificate Revocation List |
| DN |
Distinguished Name |
| ID |
Identity |
| IETF |
Internet Engineering Task Force |
| OCSP |
Online Certificate Status Protocol |
| OID |
Object Identifier |
| ONC |
Office of the National Coordinator for Health Information Technology |
| PKI |
Public Key Infrastructure |
| RA |
Registration Authority |
| RFC |
Request For Comments |
| S/MIME |
Secure Multipurpose Internet Mail Extensions |
1.6.2 Definitions
| Term |
Definition |
| Certificate |
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. |
| Subscriber |
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
DirectTrust.org 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 DirectTrust.org.
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:
- The subjectAltName extension formatted as a dNSName, and
- 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
3.2.3.1 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.
3.2.3.2 Authentication of Human Subscribers for Role-based Certificates
No stipulation.
3.2.3.3 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 3.2.3.1.
3.2.3.4 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 DirectTrust.org.
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.
- Administrator – authorized to install, configure, and maintain the CA; establish and maintain user accounts; configure profiles and audit parameters; and generate component keys.
- Officer – authorized to request or approve certificates or certificate revocations.
- Auditor – authorized to maintain audit logs.
- 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.
5.2.1.1 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.
5.2.1.2 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.
5.2.1.3 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).
5.2.1.4 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
6.1.1.1 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.
6.1.1.2 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
DirectTrust.org 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
DirectTrust.org may establish a compliance audit process that relies on legally binding self-attestation by the CA/RA.
As an alternative to using the a DirectTrust.org 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 DirectTrust.org 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, DirectTrust.org 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, DirectTrust.org 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
DirectTrust.org 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 DirectTrust.org. This certificate policy has no specified term.
9.10.2 Termination
Termination of this certificate policy is at the discretion of DirectTrust.org.
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
DirectTrust.org 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
DirectTrust.org 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.