Digital Certificate Operation in a Complex Environment
homebackgroundprojectdocumentsdesignglossary
navigation search
search query:

The DCOCE PKI Architecture and Requirements

1. Introduction

1.1. This Document

This section is a technical overview of the architecture implemented by the Digital Certificate Operation in a Complex Environment (DCOCE) project:

1.2. Aims, authentication, encryption and signing

The primary aim of the DCOCE project was to investigate the feasibility of using digital certificates for authentication to services. Therefore, this architecture was established with that in mind and the design was aimed directly at 'authentication' certificates. However, the issue of using digital certificates for signing and encryption purposes could not be completely avoided and therefore our recommendations for such certificates were that:

  • By default the 'system' issues 'authentication' certificates
  • Users who wish to receive signing and/or encryption certificates can do so, but that needs to be explicitly stated at the time of request and separate certificate(s) should be issued for those purposes;
  • authentication certificates should be used to support requests for signing or encryption certificates (avoiding the need to physically visit the RA again);
  • Similar procedures regarding requests and issuing are followed and similar storage mechanisms used;
  • Signing and encryption certificates should have longer expiry times (probably around five or ten years) and encryption certificates need to be escrowed.

See also the notes regarding revocation.

1.3. Technical terms

PKI is seen by many to be an esoteric subject area with many technical terms. It was unfortunate that the DCOCE project even had to add some of its own! However the DCOCE project web site contains a comprehensive glossary of key terms and definitions.

1.4. Architectures for feasibility/pilot study versus production

One of the aims of this feasibility study was to consider how a public key infrastructure ( PKI) architecture can be made to fit into a higher education environment. Some of this work was to actually model what would work best, and to try to build this and pilot it where possible. Clearly on a feasibility/pilot scale, not all of the infrastructure could be afforded. Therefore, the architecture outlined in this document considers what should exist in 'production', but notes are made where the pilot study had to simplify or modify any procedures or structures. These notes appear below the main body of text as in the following example:

1.4.1. Example of particular process

A really expensive hardware accelerator must be used for this for the solution to be scalable.*

* The DCOCE project used a simple network server for this process.

Up: Contents Next: 2. Requirements and Constraints

Oxford University Computing Services Mimas Athens access management services Oxfore e-Science Centre Systems and Electronic Resources Service Joint Information Systems Committee