PKI Interoperability Models (February 2005)

2. Defining PKI interoperability

In the classical PKI scenario, someone receives a document signed with a digital certificate. The recipient must trust the creator of that certificate (the Certification Authority (CA)) to be able to confirm the identity of the sender. This is simple if the sender and recipient are using the same CA. The need for interoperability arises where the document has been signed with a certificate from a CA that the recipient does not know.

The obvious approach is to centralise as much trust as possible and avoid this problem entirely. This is reflected in the root CA and hierarchy PKI models discussed below. However, those models require tight central control and unanimous support. More flexible solutions are also considered in this article – such as cross-certification meshes, cross-recognition, bridge CAs and certificate trust lists.

PKI interoperability is often described as a “multi-layered” issue, with both technical and management aspects. For PKI sub-systems and applications to work together, all software interfaces must conform to technical standards and complex, up-to-date information about the fitness for purpose, quality and status of digital certificates is required.

A good way to explain PKI interoperability requirements is to examine PKI interoperability from the relying party’s perspective.

The APEC eSecurity Task Group defines authentication as:

The means by which the recipient [Relying Party] of a transaction or message can make an assessment as to whether to accept or reject that transaction.[1]

In the case of digital certificates, from the perspective of the relying party, there are several pieces of information required for them to be able to authenticate an incoming certificate:





Fit for purpose.

The receiver must be able to tell if the Certificate is fit for purpose

That is, was the certificate issued under circumstances that allow it to support the transaction? And did the issuer intend for the certificate to be used in this way?

In general, this information must be considered at the time the receiver’s application is designed.

Where the PKI is either closed or limited to a certain community, only particular CAs and certificate types are involved, allowing designers to “hard wire” their software to expect certificates bearing certain identifiers.[2]

In open PKIs, the software must be designed with appropriate business logic in order to process certificates and extract the necessary authority information, either from the certificates directly, or from other sources such as directories.

Certificate validity

The receiver must be able to tell if the Certificate Subject is currently valid

Typically the certificate will be checked against a Certificate Revocation List (CRL) or validated using an Online Certificate Status Protocol (OCSP) inquiry. This will ensure the certificate is currently valid, before accepting the incoming message.

Certification Authority (CA) validity

The receiver must be able to tell if the Certificate Issuer (usually a CA) is valid.

Certificate path validation will usually trace all certificates in the chain back to a recognised Trust Anchor, checking the issuer’s own certificate along the way


To meet all three of these requirements, and to achieve PKI interoperability two interoperability processes are required:

1. A political or contractual process for establishing recognition
This is used to establish that a given CA meets certain technical and management interoperability requirements. This is typically achieved through the cross-certification or cross-recognition processes discussed below.
2. A technical mechanism for conveying recognition
This is used to convey sufficient information about the standing of a CA, as established by the first process, in a machine readable form, so that receivers of digital certificates can automatically decide whether or not to accept them. There are at least four options for conveying recognition of a CA: hierarchical CA certificates, cross-certificates, certificate trust lists and a bridge CA. All of these options are discussed below.

[1] Asia Pacific Economic Cooperation, Telecommunications Working Group, Business Facilitation Steering Group, Public Key Authentication Task Group Preliminary Report, September 1997 <>.

[2] These identifiers can take the form of Policy Object Identifiers (OIDs), which identify the Certificate Policy under which the certificate has been issued, or Issuer Distinguished Names.