Recently the NHS Executive has been urging providers to ensure that they can deal with the year 2000 problem. Yet the encryption pilots use a mechanism -- X.509 certificates -- which has only a two digit date field.
X.509 has other problems. It was originally designed an an authentication protocol, with non-repudiation added as an afterthought. As a result, the support that it offers for digital signatures is less than ideal. Its trust model may be thought of as similar to a credit card -- certificates have an expiry date (like credit cards) and there is a `certificate revocation list' of revoked certificates (like the hot card list of a credit card company).
This trust model has a number of limitations, including:
Roles are also of great value in reducing the cost of administration. If a bank has 50,000 staff and 100 separate applications on its system, and one tried to administer each user's access rights separately, then this would involve managing 5,000,000 bits of security state, which would be expensive and error prone. However, all but a handful of staff can have their access rights completely specified by allocating them to one of a small number of roles, such as `teller' and `assistant branch accountant'.
Dual control is also important to prevent the compromise of a single certifier causing the entire system to fail: so long as a certificate still has one trustworthy signature, it can still be used. Such robustness is a vital attribute of medical systems.
At the very least, if X.509 is to be used, then health service specific extensions will have to be developed, tested and agreed. But it is prudent to note that although X.509 certificates are being introduced in a number of electronic commerce applications, there is a growing realisation that the standard is inadequate for more general use, and alternatives are being developed. (The front runner at present appears to be Microsoft's SDSI.)
It is also prudent to note that although the computer and communications industries are merging, their standards processes have not. Where there is a conflict, the computer industry standard usually wins. There are several reasons for this. To succeed, a communications standard must be supported by a wide range of computer systems; and the product cycle of computer companies is about fifteen months compared with fifteen years for phone companies.
The NHS already has expensive experience of this conflict. A policy to have X.400 (the phone company standard) adopted for electronic messaging is encountering resistance, as computer companies -- and independent users such as GPs -- at present see much more relevance to their business needs with SMTP instead. This mistake should not be repeated with certificates.
The IMG strategy inherits from X.509 the lack of support for necessary features such as year 2000 compliance, roles, dual control, and long-lived documents. However the GCHQ protocol, if adopted in its entirety, would introduce other problems too.
Firstly, users' keys are derived from their names; so a user whose key is compromised cannot be issued a new key, but only a copy of the same old compromised key. In addition, security labels (which in the medical context would mean access control lists) are not protected and could thus be manipulated by attackers. This is directly contrary to DTI guidance on protective security marking .
Secondly, this fragility extends to the escrow aspects. In the GCHQ proposal (and also in the Teesside and NWCS pilots as far as we can see), a single official has the power to remove all the protection offered by the cryptographic mechanisms. This is not a necessary attribute of escrow systems; the US government's Clipper initiative, for example, uses two escrow agents so that a single rogue official cannot completely break the system . So even if key escrow eventually becomes a legal requirement, it is possible to implement it much more safely than the IMG proposes to. Further problems with the GCHQ protocol are described in .
Finally, IMG agreed at the July meeting that the protocols at least would be public. It is of considerable concern that we have been supplied only with project board minutes, not with technical documentation of the protocols that have been implemented in the Teesside and NWCS pilots.