DoD PKI External Interoperability FAQ

The ECA PKI is a DoD-sponsored PKI for which DoD owns and operates the root CAs. ECA vendors offer different types of certificates for both users and devices on an individual, fee-for-service basis to support a variety of use cases. ECA PKI certificates are approved for use by DoD systems to authenticate both users and devices. However, the ECA root CAs are not publicly trusted (do not participate in the major vendor root programs).

DoD-Approved External PKIs are non-DoD organizational PKIs that have been evaluated and approved by DoD in accordance with DoD Instruction 8520.02 Appendix 3B. These PKIs are divided into six types: (1) Combined Communications-Electronics Board (CCEB) Partner PKIs (2) Federal Executive Branch Shared Service Provider (SSP) PIV PKIs, (3) Commercial Medium Hardware PKIs, (4) Commercial Personal Identity Verification-Interoperable (PIV-I) PKIs, (5) Combined Communications-Electronics Board (CCEB) Partner PKIs, and (6) Other Mission Partner External PKIs on Unclassified DoD Networks. DoD-Approved External PKIs have successfully completed PKI interoperability testing with the Joint Interoperability Test Command, and for Types 3-6, have executed Memoranda of Agreement (MoA) or of Understanding (MoU) with DoD CIO. They primarily issue end user credentials such as PIV and PIV-I certificates, and their certificates are approved for acceptance by DoD systems at DoD medium hardware-equivalent and higher assurance levels (as mapped within their policy documentation and cross-certificates with the Federal Bridge). They typically do not offer PKI certificates on an individual, fee-for-service level. They also typically are not publicly trusted (do not participate in the major vendor root programs), although the PKI vendors who operate the DoD-Approved External PKIs in some cases also operate other PKIs that are publicly trusted.

Commercial PKIs are (1) operated by vendors on an individual fee-for-service basis (e.g. you can purchase a single certificate for a single web site) and (2) participate in root certificate programs of major product vendors such as Microsoft, Mozilla, Apple, and Oracle Java.  As a result, commercial PKI certificates will be trusted out-of-the-box by those vendors and their products (operating systems, browsers, etc.). DoD Instruction 8520.02 Section 3.1.a.(4)(c) permits commercial PKI certificates to be used on most public-facing DoD web sites and services to facilitate external interoperability by ensuring those sites and services are trusted by default on non-DoD-managed clients. See the Using Commercial PKI Certificates FAQ for more information on using commercial P​KI certificates for public-facing DoD servers.

The Federal Bridge Certification Authority (FBCA) is operated by the Federal PKI Management Authority (FPKIMA) to establish reciprocal trust relationships between Federal Bridge member PKIs. This is technically implemented through the issuance of cross-certificates between member PKIs and the FBCA. DoD cross-certifies with FBCA via DoD Interoperability Root CAs (IRCA).

More information on the Federal PKI can be found at https://fpki.idmanagement.gov/.

A cross-certificate is issued from one PKI to another to extend trust to that PKI.  Cross-certificates often contain technical restrictions such as name constraints and certificate policy mappings that provide additional information regarding the subject PKI’s certificates to the issuer PKI’s relying parties, as well as protections against fraudulent, mis-issued or weak certificates.

For example, the cross-certificate issued by the DoD IRCA to the FBCA currently only maps certificate policies for user certificates issued at a DoD medium-hardware equivalent assurance level.  Any certificates issued by other Federal Bridge member PKIs that assert an assurance level that is not considered equivalent to DoD medium-hardware would not successfully validate on a system using the DoD IRCA to establish trust of DoD-Approved External PKI partner certificates.

Similarly, the cross-certificate issued by the DoD IRCA to the FBCA contains name constraints that prohibit partner PKI certificates issued with DoD name spaces from validating on a system using the DoD IRCA as the root of trust for partner certificates.

Cross-certificates can easily be mistaken for root certificates at a glance because the certificate subject name will be the name of the root CA to which the cross-certificate was issued.  A cross-certificate can be identified by looking at both the issuer and subject values of the certificate – a cross-certificate will have an issuer different from its subject and will typically contain an Authority Key Identifier (AKI) value, while a root certificate will have identical issuer and subject values and will not typically contain an AKI value.

When viewing a certification path for a trusted certificate, the top node in the path is a root certificate; any other certificate that might seem to be a root based on naming is in fact a cross-certificate.

A certificate assurance level is a qualitative measure of the confidence a relying party can have that the certificate being presented to the relying party correctly identifies the presenter.  There are two primary components to certificate assurance level:

1. How is identity proofing of the certificate holder performed at certificate issuance?
2. Where is the certificate stored?

For example, a DoD medium hardware certificate is (1) issued using medium assurance identity proofing methods and (2) stored in a hardware security module (HSM) such as the chip on a smart card.  DoD medium assurance initial identity proofing for people requires an authorized identity verifier to verify the applicant in-person using a federal government official picture identification credential (such as a DoD identification card or passport) or two non-federal government issued official identification credentials, at least one of which must be a photo ID (such as a driver’s license).

Certificate assurance levels are represented within a certificate through the inclusion of certificate policy object identifiers (OIDs) in the Certificate Policies extension of the certificate.  A PKI’s Certificate Policy (CP) includes a listing of certificate policy OIDs issued by the PKI and defines policy regarding how certificates asserting each defined OID are issued and handled.  DoD’s certificate policies are defined in section 1.2 of the United States Department of Defense X.509 Certificate Policy. Some certificates also assert OIDs from other certificate policies with which they comply; for example, the DoD PIV Authentication certificate asserts 2.16.840.1.101.3.2.1.3.13 (id-fpki-common-authentication), which is defined for PIV authentication certificates in the X.509 Certificate Policy for the US Federal PKI Common Policy Framework.

Before a PKI issues a cross-certificate to another PKI, a policy evaluation of each PKI’s certificate policy is performed and approximate equivalencies between each PKI’s defined policies are identified. These equivalencies are then documented within the cross-certificate’s Policy Mappings extension.

For example, per mapping [1] shown in the Policy Mappings of the cross-certificate issued from the DoD IRCA to the FBCA in the graphic below, the cross-certificate maps id-US-dod-mediumNPE-112 to id-fpki-certpcy-mediumDeviceHardware, meaning those two policies are considered by the issuer (DoD) to be approximately equivalent.  This means that DoD relying parties can treat certificates issued at id-fpki-certpcy-mediumDeviceHardware as they would certificates issued at id-US-dod-mediumNPE-112.  Similarly, mappings [2] and [3] indicate that both id-fpki-certpcy-mediumHardware and id-fpki-certpcy-highAssurance are considered by DoD to be equivalent to id-US-dod-mediumHardware-112.

No other certificate policies are mapped in the cross-certificate because, per DoD policy, DoD relying parties may only accept certificates issued by Federal Bridge members at certificate assurance levels equivalent to either id-US-dod-mediumNPE-112 or id-US-dod-mediumHardware-112.

There are two different methods that can be used to establish trust of DoD-Approved External PKIs:

“Cross-Certificate Trust” – A system can trust the DoD Interoperability Root CA (IRCA) and utilize certification paths that build from the partner’s PKI back to the DoD IRCA through the Federal Bridge.  The major advantages of this approach are:

(1) Simplified trust store management – only the DoD IRCA roots must be tracked and managed (rather than every single partner’s infrastructure)

(2) The policy mappings in the cross-certificate from DoD IRCA to the FBCA enforce acceptable certificate assurance levels with no additional action required on the system’s part

Typically this method is only utilized on platforms that can perform dynamic path building (fetching issuer certificates from the internet based on CA Issuer locations listed in the AIA field of a certificate), such as those utilizing Microsoft CAPI or Apple keychain, due to the complexity and dynamic nature of the cross-certificate landscape within the Federal Bridge. Default path building settings may need to be increased on the system to enable path building through the Federal Bridge to complete reliably.

Systems that do not perform dynamic path building (but are capable of processing cross-certificate extensions such as policy mappings) can still utilize the DoD IRCA and cross-certificate chain by explicitly installing every certificate in the chain, but there is significant maintenance overhead to tracking and installing new and updated cross-certificates as they are issued.

“Direct Trust” – A system can trust each partner PKI’s own root (and install intermediate/subordinate CAs as necessary based on the system platform’s requirements).  This method does not enforce acceptable certificate assurance levels, so systems utilizing direct trust must implement a separate check to ensure only certificates that assert acceptable certificate policy OIDs are accepted.  Acceptable OIDs for each DoD-approved PKI are listed in the DoD Approved External PKIs Master Document, which can be found in the documents list on the PKI/PKE Interoperability page.

With either method, systems must ensure appropriate revocation checking is configured.  All DoD-approved external PKIs publish certificate revocation lists (CRLs), and most (but not all) also offer an online certificate status protocol (OCSP) service.

Once a partner certificate has been validated, a separate authorization decision verifying that the identified user should have access to the requested content should be made before providing access to DoD information systems.

The DoD Interoperability Root CA (IRCA) certificate which establishes trust with Federal Bridge partners, as well as the US DoD CCEB IRCA certificate, which establishes trust with CCEB partners, can be found in the _DoD > Trust_Anchors_Self-Signed directory within the DoD Approved External PKI Trust Chains zip file.

Rekey is the process of establishing a new key pair for an existing certified entity.  When a PKI performs rekey of its CAs, a new CA certificate is issued with an identical name, but a different key, serial number, validity date, etc.

Once a CA has been rekeyed, new certificates issued by the CA will be signed using the latest key.  However, older certificates signed with prior keys will continue to be valid until they expire or are revoked.  As a result, systems that wish to accept certificates issued by PKIs that perform rekeys may need to trust multiple versions of that PKI’s CA certificates in order to accept all currently-valid certificates issued by that PKI.

For example, at the time of writing (October 2020), the Department of Homeland Security DHS CA4 has three currently valid certificates/keys associated with the CA.  All three would need to be trusted on systems wishing to accept DHS certificates.

Certificates typically contain an extension called Subject Key Identifier (SKI) which uniquely identifies the key certified within the certificate.  Non-root certificates and Certificate Revocation Lists (CRLs) typically also contain an extension called Authority Key Identifier (AKI) that uniquely identifies the key used to sign the certificate.  In situations such as CA rekey, where multiple certificates have been issued by the same issuer to the same subject, the proper issuance chain can be identified by matching the AKI of the subject certificate to the SKI of the issuer.

The graphic below shows an example of using AKI and SKI to identify the appropriate version of an issuer’s certificate within a PKI that rekeys CAs.

Partner PKIs are reviewed and approved in accordance with the DoD PlanDoD Instruction 8520.02 Appendix 3B. The table below shows items that must be completed prior to new infrastructure approval in various scenarios. To submit new or rekeyed infrastructure for JITC PKI interoperability testing, a package containing the following certificates should be submitted to disa.jitc.pke@mail.mil:

• Certificate(s) of CA(s) being submitted for approval
• For each subordinate CA being submitted for approval:
  • A full set of valid certificates including one of each type of end entity certificate expected to be acceptable to DoD relying parties following approval of the new infrastructure (e.g. PIV authentication, signature and encryption certificates for Type 1 & 2 PKIs)
  • A full set of revoked certificates (including all of the same types submitted in the valid set)