Frequently Asked Questions - FAQs

The ECA is a program sponsored by the DoD PKI. It consists of a Root Certification Authority (Root CA) maintained at the same facility that operates the DoD PKI Root CA, and Subordinate CAs maintained by vendors. Vendors wishing to become ECAs must pass a rigorous process that ensures their certificates are interoperable with the DoD PKI and that the policies and procedures they use to issue certificates are sufficient to meet requirements specified in the ECA Certificate Policy (CP), which has been approved by the DoD Certificate Policy Management Working Group (CPMWG). Once a vendor has been approved to operate as an ECA, the vendor is issued a Subordinate CA certificate from the ECA Root CA. If an ECA vendor leaves the ECA program, the Subordinate CA certificate for that vendor is revoked. ECA vendors recoup the cost of managing their ECAs by charging fees to issue certificates.

The process of becoming an ECA Vendor is described in the document, “Becoming an ECA Vendor.”

Web servers need only be configured to accept ECA certificates as mandated by ASD(NII). According to DoD Instruction 8520.2, “DoD private web servers providing access to DoD sensitive information except those protecting access to personal information by information-privileged individuals shall be PK-Enabled to rely on certificates for client authentication issued by DoD-approved PKIs [E3.4.1.2]. Information systems requiring PK-Enabling that include users who are DoD Partners not eligible for DoD PKI certificates shall support certificates issued by DoD-approved external PKIs [E3.4]. DoD eligible users are active duty Uniformed Services personnel, members of the Selected Reserve, DoD civilian employees, and personnel working on site at DoD facilities using DoD network and e-mail services [E2.1.9][1].” Web servers that require PK-Enabling and have users who are DoD contractors or other individuals not eligible for certificates issued by the DoD PKI must be configured to validate certificates issued by ECAs. Certificates issued by ECA CAs are approved by ASD(NII) for use by DoD information systems.

[1] The full text of DoDI 8520.2 can be found here.

Authenticating ECA certificates requires installing the ECA Root CA certificate into the local trust list of the web server. Some web servers also require installing the CA certificates for each ECA subordinate CA. The ECA Root CA certificate and subordinate CA certificates will soon be published to the Global Directory Service (GDS) and can be downloaded at a GDS public website. This service will be available soon.

Validating ECA certificates requires either the web server or the web server’s validation service to download the ECA Root CA CRL and the subordinate CA CRLs. The Root CA CRL is published every two weeks and subordinate ECAs are required to publish CRLs at least daily. Each ECA is required to publish CRLs to a publicly accessible repository. In addition, the GDS will download all ECA CRLs. This service will be available soon.

Generally, the processes for issuing and revoking certificates and issuing CRLs utilized by both the ECA PKI and the DoD PKI are technically the same and follow very similar guidelines, established within their CP, KRP and respective CPS and KRPS documents. However, ECAs only issue certificates to DoD external partners (e.g., contractors, customers, DSS investigators, etc.) who have a need to conduct business with or communicate with the DoD in a trusted manner, whereas, the DoD PKI issues certificates to active duty Uniformed Services personnel, members of the Selected Reserve, DoD civilian employees, and personnel working on site at DoD facilities using DoD network and e-mail services.

It is important to note that certificate-based authentication provides information systems with who the user is, but does not provide authorization for that user to access data or other resources. Certificate validation alone should never be used for access control. Getting a certificate from the DoD PKI requires that the subscriber provide evidence of DoD affiliation. ECAs, however, are required to verify the identity and organizational affiliation of subscribers, but are not required to verify the affiliation of subscribers with the DoD. Therefore, it is even more important that information systems accepting ECA certificates incorporate access control mechanisms that map certificate identity to authorizations. Before an ECA subscriber is allowed to access sensitive data, a DoD sponsor must validate the affiliation of that subscriber with the DoD and with the need to access that data.

Yes. Currently, all three ECA vendors: ORC, and IdenTrust offer certificates that are valid for up to three years. For more information on the specific offerings of each ECA vendor, please visit their respective websites.

No. We are seeking a sustainable business and cost model, which provides the customers with certificate services at competitive rates, while allowing the ECA to make a profit and stay in business.

DoD vendors will be directed to the web sites of the qualified ECA suppliers. The ECAs will be expected to provide registration information, including processes, policies, and cost, to DoD vendors.

Please address all questions to disa.meade.mae.list.pkieca@mail.mil, if they are of a technical nature they will be forwarded to the appropriate people promptly.

Policies are currently being drafted within the DoD requiring all contractors and other organizations doing business with the DoD to use secure means of communication. This program ensures compliance with DoD regulations. Certificates can also be used to enable and improve electronic business processes. In today’s world, where the DoD relies more and more on commercial contractors to accomplish its war-fighting mission, and where terrorism is a primary concern, the ECA PKI is a vital tool in protecting Sensitive But Unclassified (SBU) information that might give our adversaries an advantage.

External contractors and other organizations that communicate with the DoD will not be issued DoD PKI certificates. The ECA PKI program was implemented by the DoD to provide a mechanism for these external entities to obtain certificates and thereby be able to communicate securely with the DoD. In addition, DoD has mandated that most DoD private websites must be Public Key-Enabled; websites that have users who are not eligible to obtain DoD PKI certificates must allow other DoD approved PKIs such as ECA for authentication.

A hardware token can be used to import a software certificate, although the certificate would still be a software certificate. Most vendors of FIPS 140 Level 2 hardware tokens provide an import capability that will read a PKCS#12 file and load the certificate and private key onto the token. The only reason to import a software certificate onto a hardware token is for portability.

The “Web of Trust” model used by PGP does not meet the identity proofing requirements listed in the DoD CP, which ensure that holders of private keys associated with certificates are who they say they are. The current ECA vendors have undergone an extensive procedure to stand up a CA and document the operational requirements in their CPS, which meet DoD’s requirements. These requirements are detailed in the ECA CP sections 5, 6, and 8.

Only PKIs that have been approved by the DoD can be used for secure messaging of DoD Sensitive information with the DoD.

No. A server certificate is NOT a substitute for large quantities of identity certificates. A server and identity certificate are very different in function and have very unique cases in which they would be used and implemented. For more information, click on the Users/Subscribers button from the toolbar on the left.

Section 11 of the ECA CP contains an identity proofing process for certificate issuance to foreign nationals.

ECA vendors are in the process of updating their Certificate Practice Statements (CPSs). Once that is completed, the vendors can start issuing certificates to authorized foreign nationals outside of the U.S.

Contact the individual vendors for further details and timeline information.

Both the ECA Root CA Certificate and the ECA CRLs can be downloaded off of the ECA vendor web sites themselves or from GDS.

This level is intended for applications handling sensitive medium value information, with the exception of transactions involving issuance or acceptance of contracts and contract modifications. Private keys associated with Medium Token Assurance level certificates must be generated and stored in hardware tokens. Identity proofing must be done in-person, but can be performed by an ECA Registration Authority, Trusted Agent, Notary, or Authorized DoD Employee (outside the US). Medium Assurance has been mapped to DoD Medium Assurance and Federal Bridge Medium Hardware Assurance.

You may follow the directions listed here.

ECA certificates can be validated using OCSP or CRL checking. DoD RCVS does not host OCSP responses for ECA vendors, instead, you will need to configure your application to locate the OCSP responder location contained in the AIA extension of the certificates. For CRL checking, CRLs can be downloaded either directly from each ECA vendor, or they can all be downloaded from GDS. ECA CRLs may be issued more frequently than once per day, and may not have the extended next. Update period that DoD CRLs have. As a result, it is important to check for updated CRLs more frequently than once per day. It is recommended to check for updated CRLs every 6 hours.