Governmental Trust Anchor Bundle Application GuideTo begin your application, start at the top of this page and work your way down to the bottom.
Question 1: Are you a DirectTrust member?
Question 2: Is your HISP fully accredited by DirectTrust and your CA/RA accreditated by DirectTrust-EHNAC?
3. Download the required materials
4. Fill out the Pre-Application Form
5. Pay your Trust Network Services Semi-Annual Fees
What happens next?
After your pre-application form has been completed and your services fee has been processed, you will be emailed a login to gain access to your secure package-upload area that will be set up by DirectTrust.org specifically for your organization to upload your application documents. At that point, the following steps will begin.
Governmental Trust Anchor Bundle Inclusion Steps
The procedure for including HISP trust anchors into the DirectTrust Governmental Trust Anchor Bundle includes the following high-level steps:
Step 1. Trust anchor and required artifact submission
After a HISP and the utilized Certificate Authority and Registration Authority entities have achieved DirectTrust-EHNAC Accreditation for HISPs, and the appropriate network fees as determined by DirectTrust have been paid, the HISP may apply for inclusion into
the Governmental Trust Anchor Bundle.
To initiate the process, the HISP fills out and submits all requested materials to the DirectTrust Trust Network Services web site at https://services.directtrust.org/. Submitted materials include:
- All trust anchor files
- Sample end entity certificate(s) pairs chaining to each trust anchor. Each pair must consist of one certificate asserting the digital signature key usage attribute and the other asserting the key encipherment key usage attribute.
- An example of each certificate type that will be issued by the trust anchor should be submitted. Certificates types include:
- Org level certs
- Address level certs
- Example of Address level cert with validated National Provider Identifier (for NPI holders only). Both provider and organization NPIs are valid. HISPs are not required to deploy Address level certificates with validated
NPI attributes in production, but MUST prove that they have the ability to do so in the correct format.
- Attestation must be included in the HISP/CA/RA document profile outlining how the validation step requirements are met.
- If the sample end entity certificates do not directly chain to the submitted anchors, all intermediate issuing certificates in the certificate chain between the anchors and end entity certificates must be submitted.
- A list of all current intermediate CAs. This list must contain the common name of each intermediate CA.
- All necessary certificates that build a path chain from the anchor up to a specific FBCA cross certificate. The format of the chain will be in the form of a PKCS7 container of certificates.
- An example of each certificate type that will be issued by the trust anchor should be submitted. Certificates types include:
- HISP/CA/RA profile document. This includes attestation to additional HISP operational procedures enumerated in Step 2 and 3.
All required artifacts must be submitted no later than the end of business hours (EOB, 5PM ET) two business days before the next Trust Anchor Approval Committee (TAAC) meeting in order to be placed on the next meeting’s agenda. For example, if the approval
committee meets on a Thursday, all artifacts must be submitted by EOB on the Tuesday prior to the meeting. At the discretion of the Trust Anchor Approval Committee, artifact corrections and/or addendums may be accepted after the submission deadline, but must
be received by the Committee prior to the approval Committee meeting.
Step 2. Baseline trust anchor approval
After the anchors have been submitted, the Trust Anchor Approval Committee will review the HISP’s documents and the submitted anchors for baseline approval. The committee will evaluate the HISP and the submitted trust anchor(s) for compliance
against the trust bundle profile criteria. Approval criteria consists of the following:
Requirements For All Entities
- The HISP, the trust anchor’s Certificate Authority, and Registration Authorities used to validate identities MUST be in compliance with all of the requirements of the DirectTrust Accredited Trust Bundle. This bundle inherits all requirements enumerated by the DirectTrust Accredited Trust Bundle. NOTE: Members of the Governmental Trust Bundle are not required to be a member of the Accredited Trust Bundle.
- HISP controlled private keys may be protected in 2 possible abstract designs:
- Private keys may be stored and protected on a Federal Information Processing Standards (FIPS) 140 level 2 minimum cryptographic module.
- Private keys may be stored outside of a cryptographic module, but must be protected with a secret key of appropriate strength stored on a FIPS 140 level 2 minimum cryptographic module.
- Cryptographic Operations:
- All cryptographic functions that utilize the asymmetric private key MUST be performed on a FIPS 140 level 2 minimum cryptographic module, and the private key may only be decrypted and activated when loaded into the module. All other cryptographic operations may be performed on a FIPS 140 level 1 module or equivalent standards recognized by the community.
- Only 140-2 approved algorithms for Secure/Multipurpose Internet Mail Extensions (S/MIME) operations may be used.
- Direct users of address bound certificate must have the capability to provide evidence of authentication level by the end of December 31, 2017. Certain federal agencies will require NIST LoA3 authentication.
All sent messages MUST be protected using message wrapping as required in the current version of the DirectTrust Health Information Service Provider (HISP) Policy. This requirement MUST be used for both organizational and address type certificates.
Certificate Authority Requirements
- Trust anchors submitted by HISPs for inclusion into the bundle MUST meet the following requirement:
- The anchor MUST have a trust path through a cross certificate to the Federal Bridge Certificate Authority (FBCA) at FBCA medium or higher.
- The anchor must not be the cross certificate.
- No certificates in the trust path below the anchor may have cross certification.
- All end entity certificates must be issued at FBCA Medium or higher.
- All end entity certificates issued by the trust anchor (or sub anchors) MUST be in compliance with FIPS-186. Specifically, all certificates asserting the digitalSignature key usage bit must only be used for signature and verification purposes.
- Practice Note: Legacy Direct dual use signing and encryption certificates do not meet the FIPS-186 requirement.
The baseline approval process includes a checklist of items that MUST be reviewed by the approval committee. Each item in the checklist MUST be reviewed and signed off by two members of the approval committee or the appropriate member of DirectTrust staff.
HISPs will be notified of their baseline approval status by the Approval Committee within 10 business days of trust anchor submission.
Step 3. Validation of Attestation
The TAAC will review the attestation statements in the submitted HISP/RA/CA profile document for compliance with the additional HISP requirements defined in section 2 of this document. Specifically, HISP attestation will be evaluated for compliance with the
- Use of a certified FIPS 140 Level 2 cryptographic module for private key protection and for cryptographic operations when utilizing RSA private key material.
Attestation to FIPS requirements will be confirmed at the HISP’s next DirectTrust-EHNAC Accreditation audit. At the time of writing, DirectTrust-EHNAC Accreditation does not audit these criteria (DirectTrust-EHNAC Accreditation will need to update its
accreditation requirements to include these criteria). When DirectTrust-EHNAC Accreditation does audit FIPS criteria, validation of DirectTrust-EHNAC Accreditation will suffice for attestation.
HISPs will be required to submit compliance to FIPS requirements after each DirectTrust-EHNAC Accreditation audit to the trust bundle administrator. On DirectTrust-EHNAC Accreditation audit “off years” HISPs will be required to submit attestation of continuing FIPS compliance to the trust bundle administrator due on the anniversary of their DirectTrust-EHNAC Accreditation audit.
Step 4. Interoperability Testing
Any HISP that applies to the DirectTrust Governmental Trust Anchor Bundle that is not already a member of the DirectTrust Accredited Trust Anchor Bundle must successfully perform interoperability testing via the processes defined in the DirectTrust Accredited
Trust Anchor Bundle standard operating procedure document. Interoperability testing for this requirement may not apply more restrictive than that of the Accredited Trust Anchor Bundle. In other words, more restrictive policies may not be applied for the purpose of
interoperability testing. This requirement may change as more HISPs are included into the DirectTrust Governmental Trust Anchor Bundle.
Any HISP that applies to the DirectTrust Governmental Trust Anchor Bundle that is already a member of the DirectTrust Accredited Trust Anchor Bundle must successfully perform interoperability testing via the processes defined in the DirectTrust Accredited Trust Anchor Bundle standard operating procedure document except the number of HISPs will be reduced to 5 and successful testing against at least 4 HISP must be executed. All 5 tests HISPs will be selected by DirectTrust. The list may be biased but will be a diverse selection of HISPs testing the capability of the applicant’s system with other HISP implementations.
All HISPs must perform additional interoperability testing against a DirectTrust control HISP to validate compliance with the HISP and CA requirements defined in section 2 of this document. Interoperability testing against the control HISP will consist of the same steps as those outlined in the DirectTrust Accredited Trust Anchor Bundle standard operating procedure document, but will validate the following additional criteria:
- Proper use of message wrapping for messages sent from the HISP under review.
- Validation of proper key usage. Specifically the process will validate the HISP under review:
- Only signs messages with certificates that assert the digital signature keyusage bit and only encrypt messages with certificates that assert the key encipherment key usage bit.
- Uses a different key pair for encryption and digital signatures when single use certificates are utilized.
- Validation of use of approved algorithms for S/MIME operations.
DirectTrust will generate the artifacts for the additional interoperability testing.
After interoperability testing is successfully completed, the HISP under review will submit their generated testing artifacts to the Trust Anchor Approval Committee for final approval. Artifacts will be emailed to the DirectTrust Administrator.
Step 5. Final anchor approval
Upon completion of interoperability testing, the Trust Anchor Approval Committee will review the submitted anchor(s) again for final approval. The committee will review the results of interoperability testing and determine if all criteria have been successfully met as defined by the interoperability testing measures. If it is determined that the criteria has not been met, then the HISP must continue interoperability testing until all issues are resolved. The Committee also reserves the right to revaluate the criteria of baseline approval if additional issues are discovered during in the interoperability-testing phase. If baseline issues are found at this stage that result in a denial, then the HISP must go back through baseline approval and interoperability testing.
Step 6. Trust bundle generation and publication
Upon successful final anchor approval, the Trust Bundle Administrator will move the trust anchor(s) into the trust bundle anchor repository location. This repository location contains a collection of all approved trust anchors in the DirectTrust Governmental Trust
Anchor Bundle, and is regularly renewed and updated.
The Trust Bundle Administrator will then generate a new trust bundle file that includes all existing and the newly approved trust anchors using the necessary tooling. The new trust bundle will use the identical file name of the existing bundle.
Before the new trust bundle is published to the publicly accessible URL, the existing trust bundle will be backed up into a trust bundle archive location. After the existing trust bundle has been archived, the new trust bundle will be moved to the trust bundle publication URL.
Lastly, the trust bundle details page will be updated with all required information including but not limited to:
- HISP name
- HISP ID
- Trust anchor(s) common name
- CA operator name
- RA operator name
- Trust anchor(s) compliance information
- DirectTrust CP version compliance
- CP URL and CPS URL
- Issued certificate types