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

PKI Primer and Project Background

10. Practical challenges for PKI

10.1. General challenges

General challenges for the safe or reliable implementation of a Public Key Infrastructure (PKI) using X.509 digital certificates fall into several categories:

10.1.1. User administration

Running and maintaining a reliable Registration Authority (RA) or multiple RAs is a human and technical administration challenge. How do you check that the user in front of you is who he says he is? How do you keep track of all your eligible users? How can you pass on the approval for the certificate request securely to the Certification Authority (CA) .

10.1.2. User facilitation

Supporting users and ensuring that PKI-associated systems are usable, intuitive and trusted by users is a major part of making an institutional PKI work. If the systems are not intuitive, much time and effort will have to be spent writing help pages, maintaining them and then supporting users directly.

10.1.3. Technical administration of services

Implementing, running and maintaining services that use digital certificates for authentication come under the term 'technical administration'.

10.1.4. Technical administration of RA and CA

The RA and CA software and hardware must be built and maintained.

10.1.5. Legal aspects

Legal aspects of running the PKI and CA are often forgotten. However, this should be considered when thinking of the 'guarantees' that the CA is giving to services and other users as to the identity (and possibly status) of the users.

10.1.6. Trust (1)

Do outside bodies trust the PKI, and will they accept the certificates issued/signed by the CA?

10.1.7. Trust (2)

How do you 'arrange' for internal and external users and services to accept the certificates? Does the software have to be amended or updated before it will work with the certificates?

10.1.8. Revocation

Revocation is of paramount importance to running a functional PKI. However, revocation is often (usually) very poorly implemented and is probably the most problematic area related to PKI at the current time.

10.1.9. Security

Obviously closely related to Trust, the PKI must be as secure as possible and users' private keys must not be compromised.

10.1.10. Storage

Even though the storage of certificates and private keys is possibly most closely related to security, storage deserves a category of its own, due to the number of options and the critical nature of this issue. The storage medium closely affects the mobility of users and their certificates.

10.1.11. False trust

The terms 'PKI' and 'digital certificates' can be blindly trusted by users and service providers. Therefore, it is possible that you could implement a 'PKI-like' system (that has most - or all - of the aspects of PKI in place but is very insecure in one area). The set-up may be trusted more because it is called PKI, but is, in fact less secure than other authentication mechanisms (which are already widely perceived to be insecure). The way that PKI is supposed to avoid this is for the administrators of the infrastructure to publish practices/policies - such as a Certification Practices Statement - that detail how the 'infrastructure' (including the human processes) works. It is doubtful whether certain service providers will even read such statements, and even those that do will probably not have an audit system of checking these.

Another safety mechanism that was originally envisaged to avoid this problem is the 'widely-trusted Certification Authority'. For example, if Oxford University were to have a CA, it could have another widely-trusted commercial CA sign the Oxford CA root certificate. This would then convey a far wider level of trust to certificates issued by Oxford. However, at the moment, having your CA root certificate signed by a widely-trusted CA appears to be more a matter of paying some money to a provider, rather than involving a trustworthy process of security and audit.

Therefore, using the term PKI alone may cause people and service providers to place too much trust in the digital certificates. It is a philosophical point, but some may consider it to be a worse situation whereby a perceived secure system is actually less secure than a system that is already perceived to be insecure.

10.1.12. Lack of attributes on certificates?

Digital certificates, like real certificates, can contain much more information than simple proof of identity. It is possible for certificates to contain information such as the holder's sex, student/staff status, occupation and much more. These snippets of information are called 'attributes' on the certificates and would, one day, allow a person to access, for example, a women-only web site as she could prove that she was female.

These types of detailed attributes are now not often added to (or used on) digital certificates. This is because the management of this information - which is likely to change far more often than the 'identity' of the holder(!) - is seen to be too difficult. It would mean that certificates have to be revoked more often and new certificates issued. As we mentioned above, revocation is a difficult area at present, so it is better to rely on the expiry date of the certificate and not to add extra attributes.

This leads digital certificates to be of little more use (from the average user's point of view) than very secure passwords with an optional (but recommended) expiry date. When digital certificates were first thought-up, a certain degree of authorisation was almost certainly envisaged.

NOTE: We haven't talked about authorisation (aka authorization) in this primer. A definition is given in our glossary. However, the concepts mentioned above regarding 'women only' or 'staff only' services are examples of using digital certificates for authentication and (at least initial) authorisation.

The current 'best thinking' in the PKI world is that digital certificates are used for authentication only and other mechanisms are invoked - following authentication - for authorisation . This diminishes the concept and some of the utility of digital certificates.

This seems unfortunate, and it may be good to bear these downfalls in mind, so that they could possibly be overcome - and the 'extra' utility re-introduced in future. The revocation and re-issuing problems are not insurmountable even at present, but then (currently) problems of certificate presentment* arise. Nevertheless, these too are likely to be overcome in future.

* NOTE: As has been mentioned before, you can put all kinds of information on your certificate (e.g. date of birth, sex, occupation, postal address, even religion). However, when you 'reveal' your certificate, you reveal all of the information (which is undesirable if you were only trying to prove that you are over 18 years old!). In future, there will probably be mechanisms whereby only parts of the certificate are revealed, but these developments are some way off yet.

So, it may be worth reminding ourselves that some of the original great hopes placed upon the use of digital certificates have been somewhat compromised. It is almost certainly worth 'pushing on' with their use, so that this 'extra utility' can be introduced later. But for now, it is worth noting that some PKI 'systems' will be of little more utility to the end user than 'public/private key only' systems (see the previous section for details of these methodologies that use public keys, but which do not use certificates). Nevertheless, administration, broader trust, key distribution and scalability are all advantages inherent to PKI.

10.2. Practical challenges for PKI in HE and FE

In Higher and Further Education, all of the above are of equal importance to that stressed above. However, it is often said that the following pose further challenges:

10.2.1. Certification Authority

Should each institution establish a CA, or should institutions combine to have a central CA, with devolved RAs? Or should each institution have their own CA signed by a higher/national CA (and which should that be?) HE and FE institutions tend to share resources (e.g. for students on vacation in their home town) and this issue is significant.

10.2.2. Mobility and storage

Mobility of the keys, and therefore storage, is of great importance in HE or FE where users typically access services from a variety of PCs (e.g. in the library, in the department, at their usual desk and at home). This leads to two issues in turn: (1) how to allow users to load and use their digital certificate and keys on more than one computer and (b) how users should load and use certificates and keys on shared computers.

Does this mean that a storage device - such as a smart card - must be used? How do we ensure that digital certificates and private keys are removed (or disabled) from shared machines after the user has finished with them for that session?

10.2.3. Operating systems

Businesses and other organisations are often able to impose one desktop environment on all (or most) users. This is often not the case in HE and FE. The operating systems can be very varied in such institutions and a wide variety of browsers and other software are also employed.

10.2.4. Heterogeneous environments

In similarity to the above, both the services and the users' environments may be managed by different bodies within the institution. Different applications may be distributed and supported by different groups of staff. Also, different - but interacting - networks may exist and could be managed by different bodies. Despite all of this, there are certain services that may be required uniformly across the institution and groups who may have the responsibility for supporting these services may have to cover the whole organisation and ensure that the service works everywhere. This is especially true of Oxford University and so highlights the suitability of the University for a project like DCOCE.

Up: Contents Previous: 9. Other authentication methodologies Next: 11. What this DCOCE project set out to investigate

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