Digital Certificate Operation in a Complex Environment
Sections in this document:search
The DCOCE PKI Architecture and Requirements
2. Requirements and Constraints
Much has been attempted here to make the use of a infrastructure ( ) 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 or placing them on shared drives. It is from this philosophy that the idea of the Local Institution Certificate Store was born.
For those users who wish to use it, the is a place where encrypted stores containing users' and certificates are housed on a central server. It should not be possible, even for the system administrator of the LICS server, to 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 is being employed by the user (i.e. make the key management and 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).
of s are tied to the Certificate Policy in place for each type of certificate. The Certificate Policy describes the procedures used in the initial 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 levels are commonly expressed as:
The 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.
The following requirements were derived from general considerations regarding the University environment, the Joint Information Systems Committee ( ) Information Environment policy and consultations with stakeholders and other interested parties.