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

The DCOCE PKI Architecture and Requirements

2. Requirements and Constraints

2.1. Usability, mobility and the LICS

Much has been attempted here to make the use of a public key infrastructure (PKI) easy for users and especially for users to move between machines. This latter 'requirement' would not be so urgent if secure devices such as smart cards (and their drivers and full hardware support) were available and affordable. It is likely that this will be the case eventually and that this architecture may be able to be simplified at that time. In the meantime, users are not very PKI-aware and mechanisms should be put in place that avoid the temptation of very unsafe practices such as emailing private key or placing them on shared drives. It is from this philosophy that the idea of the Local Institution Certificate Store LICS was born.

For those users who wish to use it, the LICS is a place where encrypted stores containing users' private key and certificates are housed on a central server. It should not be possible, even for the system administrator of the LICS server, to decrypt these stores. Therefore, the user should be able to be confident that only she can obtain and decrypt her private key. Other users, who are either highly competent in handling their keys or who are able to store them on a secure device can opt out of using the LICS.

Usability issues were addressed in the mechanisms for issuing and managing the certificates. The project team decided that we should not hide the fact that a PKI is being employed by the user (i.e. make the key management and authentication steps as transparent as possible). This arose from the overall findings, from the project consultations, that users - and the security of the PKI - will benefit from an awareness of the authentication steps occurring and the importance of the ' secret' private key

One final constraint - added by the project team - was to ensure that the architecture and technologies used did not preclude the future production of certificates that provide medium level assurance (see next section).

2.2. Assurance level

Assurance levels of PKIs are tied to the Certificate Policy in place for each type of certificate. The Certificate Policy describes the procedures used in the initial authentication of the individual and therefore gives some guidance as to how a third party should trust that certificate The perceived level of trustworthiness gives rise to the Assurance level. Assurance levels are commonly expressed as:

  • Minimum level
  • Basic level
  • Medium level
  • High level

The DCOCE project team decided to provide a mechanism for issuing certificates that should be considered to provide basic level assurance. This is because this level of assurance is all that is required at the moment and the provision of medium level assurance certificates would have a prohibitively high cost, due to the fact that many infrastructure requirements are not yet in place. It is likely however that the migration from basic level to medium level should not be too onerous in the future.

2.3. Requirements

The following requirements were derived from general considerations regarding the University environment, the Joint Information Systems Committee (JISC) Information Environment policy and consultations with stakeholders and other interested parties.

  1. The perceived level of security should be as good as that required/used by the majority of current University administered services that use authentication but better than the system of passwords "used in the clear".
  2. It should be possible to devolve registration to departments and colleges.
  3. The public key Infrastructure (PKI) needs to be easily integrated with existing staff and student University registration procedures.
  4. Where possible, the best current technology and standards should be used for good interoperability.
  5. The DCOCE PKI should support authentication using HTTP based and non-HTTP based protocols.
  6. Everything must be easy to use for the non-technical user.
  7. The number of times a pass phrase must be entered by the user should be minimised.
  8. The authentication mechanism and the certificate format must allow for integration with authorization protocols.
  9. The DCOCE PKI should provide the user with a secure mechanism to move his private key between different machines.
  10. No private or sensitive information should be stored on the certificates
  11. The user's name or personal details should not be discernable by a body outside of Oxford University. This is a common requirement for information environments and was adopted for the project in order that it meet the requirements of a wide variety of institutions.
  12. The organisational unit must be included on the certificate because colleges and departments may be registered for separate services. (This requirement gives rise to a difficulty where individuals belong to several departments or colleges and blurs the boundary between authentication and authorization).
  13. The mechanisms employed by the DCOCE PKI should not preclude or mandate the use of cryptographic hardware tokens.

    In addition to the above, the following 'requirements' were listed as optional, due to the fact that they are strongly desirable. However, (as suspected at the start of the project) there was no time to actually achieve these 'requirements' within the architecture that was built.

  14. The DCOCE PKI should provide a mechanism to allow the registration of users who cannot physically visit the University.
  15. The DCOCE PKI should provide a mechanism to reduce the risk of leaving long-lived certificates (or the private keys for these long lived certificates) on public machines.

Up: Contents Previous: 1. Introduction Next: 3. Architecture and Components

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