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

The DCOCE PKI Architecture and Requirements

3. Architecture and Components

3.1. Overall Architecture

Figure 3.1, below illustrates the general architecture of the DCOCE PKI. This architecture was proposed as a suitable solution for the requirements of Oxford University, given the available technology and the level of understanding of most users. The project team assumed however, that the design could well persist as technology develops and becomes more PKI-friendly. (Note that Figure 3.1 gives a conceptual account of the procedures and general architecture. Thus, there are extra details that are not included in the actions illustrated in this figure).

The overall architecture is comprised of the following components:

3.1.1. The User

The general user will at least have a web browser that is fairly up to date. The user will be a able to register at the University and to follow some basic instructions outlining how to obtain her digital certificate and to generate her private key

Illustrative figure showing the registration/enrolment
                      process for obtaining a certificate.

Figure 3.1 Summary of general architecture of the DCOCE PKI. (Note that stage 7 is optional and that - if that option is taken - the encrypted private key can be sent to the LICS database in step 1 or 2).

3.1.2. The central Registration Authority System (cRAS) and multiple devolved RAs

The central Registration Authority System cRAS keeps logs of certificate requests and mediates the requests to the Certificate Authority (CA). Physical/human initial authentication is devolved to multiple RAs around the University, at departmental, college or group level. However, the personnel running the cRAS provide a point of expertise in RA matters and oversee many technical aspects.

3.1.3. The Certification Authority (CA)

The CA performs the classic PKI CA role of signing certificates on the basis that the applicants have been through the appropriate registration procedures as outlined in the Certification Practice Statement.

3.1.4. The Local Institution Certificate Store (LICS)

This is a store of PKCS#12 and PKCS#8 containers where the private keys are encrypted. These may be called upon if the end user needs to use his certificate and private key from a different machine. The encrypted containers are delivered, on request, upon the receipt of the appropriate password hash. The containers are not decrypted on the server; they can only be decrypted by the end users password, which should never leave his client hardware (typically his computer).

Note: The Pseudonyms Database should be an integrated part of a directory service, such as an LDAP server, but in this document it is usually expressed as a separate entity.

3.1.5. The Pseudonyms Database

Within the pseudonyms database, users' Distinguished Names on their certificates are held next to a real name, possibly a local network name. This database may be accessed by trusted services within the institution, but should be inaccessible by external services and other users. The Pseudonyms Database has a role in identifying users for revocation and possibly, renewal purposes as well as providing a means to track down users in case of abuse of credentials.*

* The DCOCE project used a simple local lookup for this step but it would make sense to house these data within an institutional directory services database in a production environment.

Up: Contents Previous: 2. Requirements and Constraints Next: 4. Architecture and Procedures

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