Digital Certificate Operation in a Complex Environment
Sections in this document:search
The DCOCE PKI Architecture and Requirements
3. Architecture and Components
, below illustrates the general architecture of the . 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 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
The central Registration Authority System keeps logs of certificate requests and mediates the requests to the Certificate Authority ( ). Physical/human initial is devolved to multiple RAs around the University, at departmental, college or group level. However, the personnel running the provide a point of expertise in matters and oversee many technical aspects.
The performs the classic 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.
This is a store of 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 from a different machine. The containers are delivered, on request, upon the receipt of the appropriate password . The containers are not 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.
Within the pseudonyms database, users' 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 and possibly, renewal purposes as well as providing a means to track down users in case of abuse of credentials.*
* Theproject 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.