Query+for+Digital+Certificate+Use+Case



**Consensus has been discontinued for this Use Case following Charter (and scope) revisions and the decision made by the Certificate Discovery SWG members during the 7/5 meeting.** **Please see the consensus page to review associated votes.** To view disposition to comments received through the Wiki discussion threads and during consensus, please click this [|Review Log Spreadsheet]. toc

**1.0 Preface and Introduction**
To fully realize the benefits of health IT, the Office of the National Coordinator for Health Information Technology (ONC), as part of the Standards and Interoperability (S&I) Framework is developing Use Cases that define the interoperability requirements for high priority health care data exchange to maximize efficiency, encourage rapid learning and protect patients’ privacy in an interoperable environment. These Use Cases address the requirements of a broad range of Communities of Interests including, patients, providers, vendors, laboratories, standards organizations, public health organizations and Federal agencies.

These Use Cases describe:
 * The operational context for the data exchange
 * The stakeholders with an interest in the Use Case
 * The information flows that must be supported by the data exchange
 * The types of data required in the data exchange

The Use Case is the foundation for identifying and specifying the standards to support the data interoperability and developing reference implementations and tools to ensure consistent and reliable adoption of standards.

**2.0 Overview and Scope**
The Provider Directories Initiative focuses on identifying the requirements, core data set, standards, and certification criteria that will support querying of Provider Directories to determine a recipient’s electronic address and any required security information such as digital certificates in order to support electronic exchange of health information. The initiative will over time encompass a number of use cases related to Provider Directories.

The scope of this Use Case includes requirements and core data set to enable a system to query Certificate Directories for digital certificate(s) (refer to Glossary). The digital certificate(s) obtained from the query will facilitate secure exchange of health information. This capability is used by the Certificate Directory Consumer System to obtain a Digital Certificate prior to secure communication with the target of their communication where the communications mechanism does not provide certificate discovery automatically (e.g. Message Based End-to-End Encryption).

This Use Case aligns with Meaningful Use and aims to enable providers and others to electronically obtain the digital certificate of a desired destination to support secure exchange of health information.

Successful outcomes for this first Use Case include:
 * Providers and other authorized entities can retrieve digital certificate(s) to facilitate secure exchange of health information
 * Standardized query mechanism for Certificate Directories can be adopted by EHR vendors, State HIEs, HISPs and other mediators of exchange
 * Standardization and simplification of the implementation of interfaces to query Certificate Directories

There is one scenario defined for this Use Case. This scenario focuses on querying the Certificate Directory to retrieve the digital certificate(s) needed to support secure health information exchange. In this scenario, the digital certificate requester has an electronic address, but needs the ability to retrieve the digital certificate(s) by querying a Certificate Directory.

2.1 In Scope

 * Requirements, core data set and interface specification for the messaging between the digital certificate requester and the Certificate Directory that are needed to support queries to Certificate Directories to retrieve the digital certificate(s) when the electronic address is known.

2.2 Out of Scope

 * Data elements for physical addresses and attributes, beyond what is necessary for discovering the digital certificate(s)
 * Discovery of electronic address
 * Discovery using a set of attributes (other than the electronic address)
 * Verification of the digital certificate(s) against a certificate revocation list (CRL)
 * The manner in which the digital certificate requester uses the digital certificate(s) when received
 * The transport mechanism that will provide guaranteed delivery and error handling.
 * Discovery across Certificate Directories
 * Certificate Directory Sourcing Data
 * Certificate Directory Data Management
 * Directories that are used internally in organizations or systems
 * Queries or Exchanges between Certificate Directories themselves
 * Federation of Certificate Directories
 * Query for other security artifacts
 * Query for certificate by any identifier (e.g. UUID) other than an electronic address

2.3 Background
The Provider Directories Initiative addresses a central need to search for and find “discoverable” information essential for enabling health information exchange between senders and destinations. The Initiative aims to meet the immediate need for implementation specifications, guides, and standards to support EHR system certification for queries of Provider Directories and Certificate Directories under Meaningful Use Stage 2 and beyond. The Initiative also holds importance and relevance because it addresses broader requirements for secure exchange of health information.

The initial phase of the Provider Directory Initiative addresses two use cases: the discovery and retrieval of the digital certificate(s) from a Certificate Directory and the discovery of an electronic address from a Provider Directory.

The Provider Directories Initiative and the Query for Destination Digital Certificate Use Case have been selected because they align with the anticipated Meaningful Use Stage 2 criteria.

2.4 Policy Issues
There are a number of policy issues that will need to be addressed in order to realize the capabilities envisioned in the Query for Destination Digital Certificate Use Case. These include:
 * Maintenance (Sourcing Data and Data Management): The ability to maintain accurate data presents challenges for entities that own and maintain Certificate Directories. Policy direction may be needed to guide the proper maintenance of data including data reconciliation when data is received from different sources, data management, and other functions required to ensure the accuracy of data within directories.
 * Certification/accreditation of directories: Users of Certificate Directories will need a level of assurance regarding the reliability, accuracy, and security of the provider information. A certification/accreditation program may be required to ensure that Certificate Directories adopt practices and operate in a manner that will meet the standards of the health care industry.
 * Privacy and security: A risk analysis will need to be done to assess risks introduced as a result of the solution chosen for this Use Case.

2.5 Regulatory Issues
There are no regulatory issues identified for this Use Case.

2.6 Communities of Interest
Communities of Interest are public and private stakeholders that are directly involved in the business process or are involved in the development and use of interoperable implementation guides and implementation of the Solution. Some members are business actors in the use case. Communities of Interest may directly participate in the exchange, that is they are actors, or indirectly through the results of the improved business process.

The following list of Communities of Interest and their definitions have been identified for this use case: **Table 1: Communities of Interest**
 * **Member of Communities of Interests** || **Working Definition** ||
 * Clinicians || Healthcare providers with patient care responsibilities, including physicians, clinical laboratory personnel, advanced practice nurses, physician assistants, nurses, pharmacists, and other licensed and credentialed personnel involved in treating patients. Clinicians may in some instances be the owners of digital certificates maintained in Certificate Directories and may also need to query Certificate Directories. ||
 * Laboratories || A laboratory (often abbreviated lab) may need to discover the digital certificate(s) associated with the ordering or “copy to” provider associated with at lab order. ||
 * Pharmacies || Pharmacies may need to discover the digital certificate(s) of providers that they need to communicate with regarding a patient prescription. ||
 * Provider || Individuals or organizations that are engaged in or support the delivery of healthcare to include Hospital Ambulatory Centers and Provider Practices. These individuals or organizations may be the owners of digital certificate(s) maintained in Certificate Directories and may also need to query Certificate Directories. ||
 * Standards Organizations || Organizations whose purpose is to define, harmonize and integrate standards that will meet clinical and business needs for sharing information among organizations and systems. ||
 * Electronic Health Record/Electronic Medical Recorded/Personal Health Record Vendors || Vendors which provide specific EHR/EMR/PHR solutions to clinicians such as software applications and software services. These suppliers may include developers, providers, resellers, operators, and others who may provide these or similar capabilities. These software products may need to provide the capability to query Certificate Directories and then use digital certificates when sending transactions. ||
 * Federal Agencies || Organizations within the federal government that deliver, regulate, or provide funding for health and health care. These organizations may in some instances need to have discoverable digital certificates and may need to query to obtain the digital certificate(s) of other organizations. ||
 * Health Information Exchanges (HIE)/Health Information Organizations (HIO) || Health Information Exchange (HIE) is defined as the mobilization of healthcare information electronically across organizations within a region, community or hospital system. HIEs/HIOs provide mechanisms that support this electronic mobilization of health information. HIEs may create and maintain Certificate Directories that can be queried for digital certificates. HIEs may utilize third party Certificate Directory for the discovery of digital certificate(s) given the electronic address of the destination. ||
 * Beacon Communities || Selected communities of groups who have received federal funding through the ONC to build and strengthen their health information technology (health IT) infrastructure and exchange capabilities to improve care coordination, increase the quality of care, and slow the growth of health care spending. Beacon grantees may create or use Certificate Directories. ||
 * Health Associations || Professional organizations with health professionals as members focused on a joint purpose and having similarities such as specialty, medical field. They include medical associations, lab associations, pathology associations, academic organizations, other health associations etc. These organizations may create and maintain Certificate Directories that can be queried for digital certificates. Health Associations may utilize third party Certificate Directory for the discovery of digital certificate(s) given the electronic address of the destination. ||
 * Health Information Service Providers (HISP) || Entities that serve as a node on the National Health & Information Network to enable a private, secure and safe alternative method to send and receive sensitive health information. These organizations may create and maintain Certificate Directories that can be queried for digital certificates. Health Information Service Providers may utilize third party Certificate Directory for the discovery of digital certificate(s) given the electronic address of the destination. ||
 * Licensing and Certification Organizations || Organizations responsible for developing guidelines and ensuring that relevant parties adhere to those guidelines to ensure proper licensing and certification of systems and other health solutions related to healthcare. These organizations may certify vendor software for compliance with the Certificate Directory query specifications or may accredit Certificate Directories. ||
 * Public Health Agency (State/Local) || State or Local health department agencies that oversee and manage public health activities within their respective geographies. These organizations may in some instance need to have discoverable digital certificate(s) and may need to query to obtain the digital certificate(s) of other organizations. Public Health Agency (State/Local) may create and maintain Certificate Directories that can be queried for digital certificates. ||
 * Certificate Authority || An organization that is responsible for the creation, issuance, revocation, and management of Certificates. The term applies equally to both Roots CAs and Subordinate CAs. ||
 * Registration Authority || Any entity that is responsible for identification and authentication of subjects of certificates, but is not a CA, and hence does not sign or issue certificates. An RA may assist in the certificate application process or revocation process or both. ||

3.0 Challenge Statement
Health information exchange requires a mechanism to obtain a digital certificate(s) to facilitate secure exchange of health data. Today, this functionality is generally supported by consistent and standardized electronic means, but not adopted widely. A scalable and standardized solution will be needed in order to efficiently, accurately, and reliably query and obtain digital certificates to enable health information exchange.

4.0 Value Statement
The ability of systems to query Certificate Directories to obtain digital certificates is needed to facilitate secure exchange of health data. Currently, there is widely available functionality that enables a sender to electronically obtain the digital certificate(s) for an intended destination. However, when the exchange of the health data crosses organizational boundaries, additional functionality is needed. A scalable and standardized method to enable senders to query and obtain digital certificates will facilitate secure health information exchange.

5.0 Use Case Assumptions

 * The digital certificate requester system has the electronic address associated with the digital certificate being requested
 * The digital certificate requester system can access the external Certificate Directory
 * Digital certificate requester systems will be able to send electronic address for Certificate Directory searches
 * Digital certificate requester systems will be able to incorporate digital certificates into messaging
 * If the Certificate Directory has a pointer to the digital certificate, it can retrieve it and return it to the digital certificate requester system
 * The Certificate Directory can retrieve both digital signature and encryption certificate(s)
 * Expired digital certificates will not be returned
 * Certificate Directories ensure that their data is accurate, timely, and complete in keeping with relying party agreement
 * In keeping with relying party agreement, legal and governance issues regarding data access authorizations, data ownership, and data use are in effect.
 * Established network and policy infrastructure to enable consistent, appropriate, and accurate information exchange across provider systems, data repositories and locator services. This includes, but is not limited to:
 * Methods to identify and authenticate users;
 * Methods to enforce data access authorization policies;
 * Methods to ensure the veracity of data;
 * Detailed audit trails are kept by all participating systems.
 * Security and privacy policies, procedures and practices are commonly implemented to support acceptable levels of privacy and security; i.e., HITECH and EHR certification criteria.
 * The Certificate Directory and certificate authority must be part of an approved trust framework
 * A Certificate Directory will provide at least one secured and guaranteed delivery transport mechanism
 * More than one digital certificate can be retrieved from the Certificate Directory for a given electronic address
 * All applicable Federal, State & local regulations are being supported.

6.0 Pre-Conditions

 * The digital certificate requester or the digital certificate requester system has identified a need to electronically send information to a destination
 * The digital certificate requester or the digital certificate requester system has the electronic address for the intended recipient
 * The digital certificate requester system has been configured to determine the Certificate Directories that may receive a query
 * Certificate Directories are available and can respond to queries
 * Certificate Authority trust relationships have been established
 * Certificates have been issued and placed in Certificate Directory

7.0 Post Conditions

 * The digital certificate requester system selects the correct digital certificate when multiple certificates are returned
 * The digital certificate requester system validates the digital certificate returned by the Certificate Directory.
 * The digital certificate requester system has the digital certificate to meet its requirements

8.0 Actors and Roles
This section describes the Business Actors that are participants in the information exchange requirements for each scenario. A Business Actor is an abstraction that is instantiated as an IT system application that a Stakeholder uses in the exchange of data needed to complete Use Case action(s); a Business Actor may be a Stakeholder. Furthermore, the systems perform specific roles in this Use Case as listed below:

**Table 2: Actors and Roles**
 * **Actor** || **System** || **Role** ||
 * Certificate Directory || Certificate Directory || The Certificate Directory performs the function of processing the Certificate Directory Consumer Query to search for the digital certificate(s) based on the destination’s electronic address and to return the certificate(s) if available. ||
 * Certificate Directory Consumer || Certificate Directory Consumer System || The Certificate Directory Consumer actor initiates a Certificate Directory query to the Certificate Directory actor indicating the electronic address of interest and receives the certificate(s) if returned. ||

9.0 Use Case Diagram
The following diagram depicts the query for digital certificate information defined in this use case. **Figure 1: Use Case Diagram**

**Figure 2: Context Diagram**

**10.0 Scenario:**
This use case contains one scenario. In this scenario, the digital certificate requester has an electronic address associated with the digital certificate being requested and queries a Certificate Directory to retrieve the digital certificate(s).

10.1 User Story: Push
The digital certificate requester or the digital certificate requester system has a known electronic address associated with the digital certificate being requested. The digital certificate requester’s system does not have the digital certificate(s) associated with the electronic address. The digital certificate requester system sends a query to the Certificate Directory without user intervention. The Certificate Directory returns zero or more digital certificate(s) associated with the electronic address. The sender system verifies that Certificate Directory has returned the appropriate certificate for the electronic address and that it has been issued by a trusted authority. The digital certificate requester system is able to use this digital certificate to support its requirements. .

10.2 Triggers

 * **Triggering Event** || **Specific Pre-Conditions** || **Description** ||
 * A digital certificate user determines that a digital certificate is required || The digital certificate user has the electronic address associated with the digital certificate to be retrieved and the means to send requests and information electronically ||  ||

10.3 Activity Diagram
The visuals below depict a combination of all events described in the scenario flows which are described in further detail in the tables that follow. **Figure 3: Activity Diagram**

**10.3.1 Base Flow**
**Table 4: Base Flow**
 * **Step #** || **Actor** || **Role** || **Event/Description** || **Inputs** || **Outputs** ||
 * 1 || Certificate Directory Consumer || Digital Certificate Requester || Sends electronic address || Electronic address || Electronic address ||
 * 2 || Certificate Directory || Query Responder || Sends digital certificate(s) associated with the electronic address || Electronic address || Digital certificate(s) associated with the electronic address ||

**10.4.1 Information Interchange Requirements**
**Table 5: Information Interchange Requirements**
 * **Initiating System** ||  || **Information Interchange Requirement Name** ||   || **Receiving System** ||
 * Certificate Directory Consumer System || Send || Query for digital certificate || Receives || Certificate Directory System ||
 * Certificate Directory System || Send || Digital certificate associated with the electronic address || Receives || Certificate Directory Consumer System ||

**Table 6: System Requirements**
 * 10.4.2 System Requirements**
 * **System** || **System Requirement** ||
 * Certificate Directory Consumer System || Form a query for digital certificate ||
 * Certificate Directory System || Return digital certificate that matches the electronic address ||
 * Certificate Directory Consumer System || Receive digital certificate ||

**Figure 4: Sequence Diagram**
 * 10.5 Sequence Diagram**

**11.0 Issues, Obstacles, and Potential Risks**
There are a number of issues that may impact the implementation or effectiveness of this use case
 * The limited experience in the healthcare industry with the creation and use of Certificate Directories for the intended uses described in this use case.
 * The lack of extensive experience in the implementation of the existing standards
 * Ensuring that there are consistent and reliable mechanisms for updating
 * The absence of a mechanism, such as accreditation, to ensure that Certificate Directories are reliable and have appropriate control and security
 * Providers are not broadly experienced in acquiring and using certificates
 * Concerns that providers may have about sharing their information
 * Security risks posed by sharing electronic addresses
 * Security risks posed by metadata in the digital certificate
 * Security risks based on spoofing and other attacks on the Certificate Directory
 * Capability of digital certificate requester systems to use and manage digital certificate
 * Potential for misidentification of a destination and the inappropriate sharing of PHI
 * Adoption and utilization of messaging frameworks that permit the directed exchange of healthcare information between individuals and entities engaged in healthcare is limited by the actual and perceived threats to the users of the discovery of personal or sensitive information and the potential for violations of trust (e.g. through the sending, receiving, and interception of information by individuals and entities not engaged in the care process)
 * If implementers should be aware of the fact that if they elect to use a Certification Authority that is not cross-certified with the Federal Bridge that they may not be interoperable with the federal entities using the Direct Project. Thus, the S&I Framework PD Sprint team requests that the ONC issue guidance on the requirement to use a Federal Bridge cross-certified Certification Authority.
 * The risks to the sender and receiver of healthcare information associated with digital certificates where the trust chain does not terminate on a “healthcare” trust anchor that has certification process specific for healthcare entities and individuals is unknown.
 * The required content (metadata) for “healthcare” digital certificates is currently unknown and may include information reasonably considered sensitive or private to providers.
 * The determination of who (individuals and entities) can obtain a Healthcare Digital Certificate, the use requirements that must be agreed to by the recipient of the certificate and the standards for use/misuse of the Digital Certificate that will result in the revocation of the certificate have not been established and may create risks for the sender or recipient of the healthcare information.
 * There is risk to the sender and receiver of health care information as identified in this use case if a suitable forum is not established to identify and address threats (e.g. man-in-the-middle, spamming, phishing, denial of service) to the users of messaging frameworks that rely on publically available Digital Certificates (e.g. those that are available via DNS) for the exchange of healthcare information.
 * Risks exist to the sender and receiver of health care information if implementation of the type of messaging anticipate by this use case does not provide the ability to:
 * Validate the trust chain, ownership and status of Digital Certificate(s) retrieved by the sender for the intended destination
 * Validate the trust chain, ownership and status of the sender’s certificate by the recipient
 * Establish a “blacklist” and/or “whitelist” process to reduce unwanted messages and/or establish a trust chain between the sender and recipient prior to the delivery of the message to a user’s inbox or clinical application
 * Provide standard response to the sender of a message to indicate the status (rejected, not in whitelist, accepted, etc.) for messages that have a valid certificate that chains to an appropriate trust anchor.

12.1 Message Content Requirements
The following table lists the expected content of a Certificate Directory query message.
 * **Section Description** || **Data Elements (Required if available and applicable to support use case but not inclusive of any underlying standards )** || **Additional Notes** ||
 * Digital Certificate Owner Identification Information || Electronic address ||  ||
 * Digital Certificate(s) || Issuer, effective dates, public key, policy || This could be zero if no certificate is found and can send multiple certificates. A return of zero certificate could be a result of a denial or no certificates ||
 * Table 7: Dataset Considerations for Query Message **

The following table lists the expected content of a Certificate Directory return message. **Table 8: Dataset Considerations for Return Message**
 * **Section Description** || **Data Elements (Required if available and applicable to support use case but not inclusive of any underlying standards )** || **Additional Notes** ||
 * Digital Certificate(s) || Issuer, effective dates, public key || This could be zero if no certificate is found and can send multiple certificates. A return of zero certificate could be a result of a denial or no certificates ||

Appendix A: Related Use Cases
The Use Cases included in this section may be related to the Query for Destination Digital Certificate Use Case.
 * IHE Healthcare Provider Directory (HPD) Profile Provider Information Query Transaction Use Cases
 * HIT Policy Committee Information Exchange Workgroup Entity Level and Individual Level Provider Directory Use Cases
 * HL7/OMG Version 3 Standard Healthcare, Community Services and Provider Directory Use Cases

Appendix B: Previous Work Efforts Related to Provider Directories
NOTE: This list should not be considered inclusive.
 * IHE Technical Framework Supplement Healthcare Provider Directory (HPD) Profile: This profile supports queries against, and management of, healthcare provider information that may be publicly shared in a directory structure.
 * HL7 Version 3 Domain Analysis Model: Interdependent Registries, Release 1: This specification aims to fulfill administrative and continuity of care use cases using electronic communication between information system
 * HL7/OMG Version 3 Standard - Healthcare, Community Services and Provider Directory, Release 1: This includes a Service Functional Model that describes the specific functions for Shared or Colloborative Care
 * ASC X12N 274 Provider Directory: This includes two implementation guides, ASC X12 004050X109 which is the Provider Directory and ASC X12 004050X185 which is the Provider Inquiry and Response
 * LDAP (Lightweight Directory Access Protocol): This internet and application protocol supports the storing of information in and editing of directories over an IP network
 * DNS (Domain Name System): A hierarchical naming system built on a distributed database and that translates domain names that are meaningful to humans into numerical identifiers of networking equipment in order to locate and address multiple devices.

Appendix C: Glossary
These items are included to clarify the intent of this use case. They should not be interpreted as approved terms or definitions but considered as contextual descriptions. There are parallel activities underway to develop specific terminology based on consensus throughout the industry.


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


 * Certificate Directory:** A system that either stores digital certificates or has a listing of sources such as Certificate Authorities where digital certificates are stored and can be obtained. This role may be carried out by a Provider Directory


 * Certificate Validation:** A process that includes an algorithm to verify that a given certificate path is valid under a given[| public key infrastructure (PKI)]. It involves checking the validity of a certificate within a trust chain and against any kind of certificate revocation list.


 * Destination:** The intended recipient who owns the electronic address used in the query for digital certificate

A digital certificate has metadata information about the destination
 * Digital Certificate**: an electronic document that certifies that the subject (person or entity) has been issued a pair of encryption keys that are related in such a way that if one key is used to encrypt something (e.g., file, message, and data stream), it can be decrypted only by someone holding the other key
 * One key is published for anyone to see (“public key”). A public key certificate is a digital certificate binds a system entity's identity to a public key value, and possibly to additional data items and it is a digitally signed data structure that attests to the ownership of a public key
 * Other key is kept secret by the entity/person to whom the digital certificate has been issued (“private key”)


 * Digital Signature:** The result of a transformation of a message by means of a cryptographic system using keys such that a Relying Party can determine: (1) whether the transformation was created using the private key that corresponds to the public key in the signer’s digital certificate; and (2) whether the message has been altered since the transformation was made.


 * Electronic Address:** A string which identifies the transport protocol and end point address for communicating electronically with a recipient. A recipient may be a person, organization or other entity that has designated the electronic address as the point at which it will receive electronic messages. Examples of an electronic address are an email address (Direct via SMTP) or URL (SOAP / XDR). Communication with an electronic address may require a digital certificate.


 * Entity:** An organization or a department, on the sending or receiving side, that may have an electronic address.


 * Encryption Certificate:** A certificate containing a public key that is used to encrypt electronic messages, files, documents, or data transmissions, or to establish or exchange a session key for these same purposes.


 * 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.


 * Provider**: An individual on the sending or receiving side, that may have an electronic address.


 * Provider Directory**: An electronic, searchable resource that lists all information exchange participants, their names, addresses, and other characteristics. A Provider Directory can carry out the role of a Certificate Directory.


 * 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 (PKI):** 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.


 * Sender: An individual or entity on the sending side** that may have an electronic address and needs to query for the digital certificate(s).


 * Digital Certificate Requester System**: The electronic system used by a digital certificate requester


 * Trusted Authority**: An entity that has been trusted to issue or manage digital certificates


 * Trusted Framework**: A complete chain of trust that includes the Certificate Authorities, Certificate Directory, the Consumer, the Destination, and the security of the messaging framework.

Appendix D. References

 * Query for Electronic Address Use Case
 * HITSC Privacy & Security Workgroup Meeting Materials on Digital Certificates: []
 * Federal Public Key Infrastructure Policy Authority (FPKIPA): []
 * The Direct Project Session 5 (Provider Directories): []
 * CA Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates : []
 * FPKIPA Criteria and Methodology For Cross-Certification With the U.S. Federal Bridge Certification Authority (FBCA): []