PKI Interoperability Models (February 2005)

[« previous] [next »] [title page] [full contents]

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:

 

 

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 <http://www.apectelwg.org/apecdata/telwg/eaTG/eaTG-1.html>.

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

[« previous] [next »] [title page] [full contents]

[view all] [download PDF version]

[up to research]