1. Introduction

i) This document is a response to the Department of Trade and Industry consultation paper [1], reference URN 99/642.

This response is written by Melanie Dymond Harper on behalf of Herald Information Systems [2], an Internet and security consultancy based in Surrey, and should be construed as the official opinion of both parties on this matter. Dr Harper is also the UK representative of Thawte Certification [3], a major certification authority based in South Africa, but this document should not be construed as the official opinion of Thawte Certification.

2. General notes

i) We note that the consultation period for this document is extremely short. Given the long period of time that has elapsed since the last consultation (our comments on the last consultation paper, "Licensing of Trusted Third Parties for the Provision of Encryption Services", were sent on 30th May 1997), it would have seemed reasonable to allow the industry longer to prepare their comments. This is especially true since, on reading through this paper, it appears that the Government do not have any ideas on how some of their proposals should be implemented, and are looking to industry to provide the answers. While we would normally applaud this, it takes longer to come up with new techniques and suggestions than it does to comment on existing plans.

3. Legal recognition of electronic instruments

i) It is our view that the preferred method of updating current legislation to allow for the possibility of replacing conventional signatures and writing would be by statutory instruments, rather than by individual pieces of primary legislation. We agree that the length of time necessary to enact the primary legislation would unduly restrict the growth an industry developing so quickly. However, it will be necessary to consult those affected at each stage of the process, and to take advice from industry to ensure that the resulting legislation is as technology-neutral as it can sensibly be made.

ii) One option that is not discussed in section 19 of [1] is the possibility for the use of role-based, rather than personal, signatures. By this we mean that it would be possible to have a document signed such that it could be proven that the signatory was a director, or other authorised signatory, of a particular company; the director's name need not be part of the signature. It is not always necessary, nor indeed desirable, to have signatures "uniquely" linked to the signatory. An excerpt from the standard authorisation letter used by Thawte Certification (used with their permission) reads:

"I, <name>, hereby approve the use of a Thawte Digital Certificate for secure and authenticated electronic transactions by <company name>. I hereby represent that I am fully authorized to make such approval, and that I understand that a digital certificate acts as a company stamp or director's signature for the purposes of electronic commerce, and that the management of the private keys associated with such certificates is the responsibility of our technical staff or contractors."

As can be seen, this emphasises the responsibility associated with the certificate, but does not necessarily bind it to a single natural person (though most usually to a single juristic person). Note also that, although the legal person to whom the certificate is issued can maintain the private key under their sole control, it is not at all unusual to delegate control of that key to an employee or department within a company, or to an Internet Service Provider or other external contractor.

iii) Section 21 of [1] makes no mention of any possible cross-validation agreements for those Certification Authorities who are incorporated in other countries. If comparable legislation or a comparable licensing regime to that which will exist in the UK should exist in those countries, and if the Certification Authority concerned complies with that legislation and/or licensing regime, then it should be the case that certificates issued by that Certification Authority should be recognised in United Kingdom courts without the burden of proof demanded here. This could have an effect on disputes subject to United Kingdom law arising between a UK firm and a foreign firm; it makes little sense to insist that the foreign firm's certificate must have been licensed by a Certification Authority licensed in the UK. We note mention of equal application for electronic signatures created in the UK and in other EU member states, but the two largest certification authorities at present are both incorporated outside the EU (Verisign, in the US, and Thawte, in South Africa).

4. Other possible legal barriers to electronic commerce

i) We note with some concern the consideration being given to "broadening the legal equivalence of electronic writing to encompass other digital data, e.g. images, audio-visual and similar applications that are likely to develop in the future." (section 26 of [1]) While the forward-thinking stance of the DTI in this case is laudable, it should be noted that the necessity for electronic signatures to provide authentication, integrity and non-repudiation will probably still exist with these technologies -- we believe that it is the signature technology that should be under scrutiny at this stage, rather than the item being signed. Once data is entered into a computer it matters little whether it is text, graphic, video, audio or other input -- so long as it can be signed and transmitted.

5. Other legislative possibilities

i) Any preference scheme regarding unsolicited e-mail (section 29 of [1]) must be opt-in, not opt-out. This is especially true for those users who dial an Internet Service Provider to receive e-mail. At present, many unscrupulous "spammers" advertise that they will remove you from their e-mail list if you reply to their message, including particular text; in practice these "spammers" usually then add your e-mail address to an even more sought-after list, that of valid e-mail addresses where the mail is actually read. Others insist that you must call or fax a certain number to register your disinterest in receiving further mails (and this number is almost invariably a foreign number).

ii) We believe that business-to-business transactions (section 30 of [1]) should also be covered by any anti-"spamming" legislation. There is no basis for allowing facilities belonging to a company to be abused in this manner.

iii) "Spoofing" (section 31 of [1]) is occasionally useful (and valid) for users working on remote sites or outside their normal place of business (for instance, if they are dialled in from their home but would prefer that their e-mail appear to come from their normal office address). A better wording for this section might be to prohibit malicious misrepresentation of the origin of the e-mail; for instance, sending mail bearing someone else's identity. A further suggestion would be an amendment to the Computer Misuse Act to specifically disallow the use of another's system for sending mail without the permission of the owner of that system.

6. Licensing regime for trust service providers

i) As a general preface to this section we would refer the Department to the BESTS (Business Environment Study of Trusted Services) project, funded by the European Union, which finished at the end of last year. [4]

ii) Section 35 of [1] contains a misconception about the role of a Certification Authority at the present time. Certification Authorities do not, in general, have any interest in storing the private key of a key pair generated for authentication purposes. Typically the user's public key is sent to the CA for signature by the CA; the CA never sees the private key and thus cannot store it. A reputable CA will emphasise to the user that their private key must be kept securely, and also that they should keep a back-up of the private key in case of malfunctions. (See also section 8(i) below.)

iii) We are pleased to note that the Government has decided to consult on the basis that neither key escrow nor key recovery will be necessary for providers of confidentiality services (and that the division between confidentiality and authentication services has been recognised in this consultation paper as it was not previously).

iv) The box on page 20 of [1] implies that key generation is a core service for a Certification Authority. We do not believe that this is the case. The key pair is most usually generated by the company or individual who wishes to sign documents or to encrypt traffic; the CA does not generate this for them.

v) It should be noted at this stage that the certificates used by secure Web servers are authentication certificates and not encryption certificates (and hence the Certification Authorities providing them would expect to be licensed as providers of authentication technology and not encryption technology). The certificate containing the public key of the person or company owning or operating the secure server is presented to the browser, and then that public key is used by the browser to negotiate a session key for the following encrypted session; that session key will never be known to the CA who issued the server certificate.

7. The licensing authority

i) We note that the possibility exists for an anti-competitive situation in the case where functions of the licensing authority would be contracted out. It is quite possible to imagine that those firms currently providing security audit services, or other firms within the telecommunications industry, would also be interested in providing trust services. We would prefer that OFTEL either not contract out its functions in this area, or that it contracts out its functions only to firms who are contractually obliged not to provide trust services.

8. Liability

i) There are many potential pitfalls to be avoided in this area. As detailed in section 44 of [1], there are several different parties who must be considered when setting rules on liability. At present, Thawte Certification have a simple statement regarding liability:

"Thawte hereby accepts liability (excluding punitive damages) for any negligence in the performance of its verification practices."

But note also:

"A subscriber is solely responsible for protecting its private key and must notify Thawte immediately upon discovering that its private key has been lost or compromised. Subscribers will be held liable for any misrepresentations they make to Thawte."

and

"It is unreasonable for any party to rely on a digital certificate if that party has actual or constructive notice that the certificate or key may have been compromised. Constructive notice includes but is not limited to all facts listed in the certificate or incorporated in it by reference, as well as the contents of this CPS. It is further unreasonable for that party to rely on the certificate if it has not checked the Thawte Certificate Revocation List."

(both also from Thawte's Certification Practice Statement)

This shows a division of responsibility between the three differing needs. Thawte accepts that, if they are negligent in their duty of care, then they are liable for that negligence; but they also remind the purchaser of a certificate (the "subscriber" mentioned in the second quoted paragraph above) that they must exercise care with regard to their private key, and they advise any third party who may wish to rely on a given certificate that they should confirm the certificate's validity before so relying. (If a certificate is presented at a time within its validity period, if that certificate does not appear on Thawte's Certificate Revocation List, and if the certificate is signed by a recognised Thawte Certification key, then that certificate may be assumed to be valid.)

ii) It is our opinion that the "duty of care" mentioned in section 45 of [1] should be mentioned in documentation relating to this issue, though perhaps not specifically legislated. Mandating a specific number of hours as the time period within which a Certification Authority must be notified of the compromise of a private key is perhaps unwise, given that the CA may not be in the same country as the user concerned, and may require such notice to be in writing -- as the key signed by the CA can no longer be relied upon for authentication. We would prefer to see wording such as "as soon as reasonably practicable".

9. Licensing fees

i) Notwithstanding our comments in 7(i) above, we would welcome either consultation with the industry or competition within the market in the matter of licensing fees.

10. Law enforcement interests in cryptography

i) Despite the Government's evident interest in the promotion of key escrow schemes (even if they are not to be a legal requirement) we do not believe that the ordinary user of cryptographic services, whether for authentication, encryption or other uses, will be interested in the use of key escrow. While we understand the difficulty that the use of encryption poses for law enforcement, the benefits of key escrow for the home or small business user are not significant enough to encourage its use. The only people who we would expect to take up key escrow services would be larger businesses where key recovery in the case of the death, dismissal or departure of critical personnel is an issue of concern. Smaller businesses and individuals will have no compelling reason to hand over their private keys -- and criminals, still less so.

ii) It should be possible to issue a warrant that will require a person to give up a particular private key (for instance, "the key to decrypt this specified message"). There are significant self-incrimination issues to be addressed if a warrant were to be issued for, to take an example, "the keys to decrypt all data on this computer drive". This would almost certainly fall outside the principle of requiring someone to provide only relevant information, unless the law enforcement authority in question has reason to believe that everything on the drive is relevant to their case. We note also that the requirement that information be provided in a "visible and legible form" is not necessarily practical in this situation, unless "legible" is extended to include data stored in unencrypted form on a computer disk.

iii) One way around this might be to require, not the private key to decrypt a particular message, but the plain text of that message (as suggested in section 69 of [1]). In practice this will lead to difficulties of proving that a particular ciphertext C corresponds to a particular plaintext message M, and we would therefore expect that the request would usually be for the private key rather than the plain text.

iv) We note that the use of encryption is not necessarily obvious. Steganography, the practice of hiding encrypted messages in apparently innocuous data, has a long history and cannot easily be detected in use. Nor can an encrypted message easily be told from other binary data, such as pictures or sound, at first glance.

11. The needs of law enforcement agencies

i) The requirements mentioned in section 88 of [1] -- namely, that decryption should be both timely and covert -- are no longer realistically achievable, no matter how much law enforcement agencies might wish that this were not so. If the system on which the secret key is held can be broken into or confiscated, and if that secret key is not protected by a password known only to the criminal under investigation, then decryption may be a relatively simple procedure, otherwise the decryption will not occur in anything like real time.

Many of the systems used to encrypt data are public knowledge, and plenty of books exist with published details of the algorithms and even source code for their implementation -- then of course there are many sites discussing encryption on the Internet, and hundreds of different pieces of software to encrypt files and e-mail (some more effective than others). The encryption genie is out of the bottle, and has been for many years; no amount of wishing, pleading or legislation will put it back. (See comments in 10(iv) above about the difficulty of detecting encryption in use.)

The best hope for the law enforcement agencies would be that criminals use systems built by themselves and not too rigorously tested, or using their own (flawed) algorithms. Restricting the use of cryptography or requiring the use of key escrow would impede the growth of electronic commerce in Britain too much for it to be a realistic option at this stage.

12. Annex A - Licensing Criteria

i) We believe that the proposed criteria as they stand are too biased towards UK-based businesses.

ii) "The owners and directors should be fit and proper people": what evidence might be provided of this for companies whose main business is conducted outside the UK? While we do not argue the necessity for such a clause, it will need to be more explicitly worded and not couched only in terms applicable only to those resident in the UK.

iii) "Registered Office in UK": there appears to be some confusion of the "licensee" versus "those responsible for running the organisation". It would seem sensible that the licensee should be the person or people (or the juristic person) responsible for running the organisation; if they have a representative in this country who can accept communications on their behalf and pass them to the licensee, all well and good, but that person will most likely not themselves be the licensee. The requirement for real-time communication is also not quite reasonable when differing time zones are taken into consideration.

iv) "Business Plan": There should be no requirement for such detail to be provided. Again we are concerned about the possibility for anti-competitive behaviour, and it seems likely that some of the information requested (for instance, the business strategy) would be confidential to the company concerned.

v) "Information Security Management": Accreditation under BS7799 would not be suitable for Certification Authorities where the information processing and/or certificate issue are carried out overseas. Other (local or global) schemes might be more appropriate.

vi) "Content of Certificate": As discussed in 3(ii) above, there is no reason why an issued certificate need include the name of the holder. Attributes of the holder are often far more useful (for instance: the holder of this certificate holds account number X at bank Y; the holder of this certificate is a doctor licensed to practice in the United Kingdom; and so forth). We would also seek clarification about the "unambiguous statement" listed here as a requirement; is it the case that this statement is to be required within keys used for signature to distinguish them from keys used for encryption? The consultation paper is not clear on this issue.

vii) "Generation of Key Pair": "If the key-pair is to be client-generated then details of the process used will need to be supplied." This process is invariably dependent on the software that the client is using. This software is, in general, neither supplied nor maintained by the Certification Authority and the details of the generation process may well not be public. We suggest that the DTI contact the publishers of the server and browser software currently available for details of the exact process used to generate keys (and we wish them good luck in obtaining this information).

viii) "Client Authentication": The definition of "physical identification" is not clear at this stage. We do not believe that the DTI actually means that the representative of the natural or juristic person wishing to purchase a certificate must present themselves at the office of the Certification Authority. We would expect that an authenticated physical communication (letter or fax) from the person concerned would be sufficient.

ix) "Legal Access": We note that the "period specified in the licensing conditions" (wherein a CA must respond to a validated written authorisation for it to produce appropriate information which it has in its possession) is not specified. This is a slight improvement over the previous consultation document which suggested a period of an hour; we would hope that the period eventually chosen would be more realistic than this.

x) "Authentication of Access Request": it is hard to begin planning procedures for this authentication when the remainder of the document is so vague about the way in which such a request might be handled, and the data which might be requested.

13. Summary

While we welcome the proposals laid out in this document as an improvement over those present in the previous consultation document, the proposals themselves are still vague on many important points and mistaken on some minor points, as discussed above. This is especially worrying given the very short period allowed for consultation. We are worried that the Government may rush into legislation -- being determined to legislate in the current session -- without sufficient consideration of the situation as it stands and the likely future developments in the technical and (extra-UK) political arena. This legislation will be vital to the future development of the United Kingdom as a country where electronic commerce can thrive, and it is of the utmost importance that the Government should consult widely -- especially among those already in the industry -- before committing itself to an inappropriate legal framework.

14. About the Author

Melanie Dymond Harper has an MA in mathematics and computation from Pembroke College, Oxford, and a PhD in discrete mathematics from Royal Holloway and Bedford New College, University of London. She has been the UK representative of Thawte Certification for the past two and three-quarter years, and has considerable experience of handling business queries about the process of acquiring a digital certificate, ranging from explanations of the mechanisms of public-key cryptography to troubleshooting installations and advising on compatibility issues.

Herald Information Systems is an Internet and security consultancy business based in New Malden, Surrey. For the last four years they have been advising businesses about use of the Internet for commercial purposes, including setting up secure servers for customer ordering.

15. References

[1] Building Confidence in Electronic Commerce - A Consultation Document; URN 99/642. 5th March 1999.

[2] http://www.herald.co.uk/

[3] http://www.thawte.com/

[4] http://www.bests.org/ . From their Web site:

"This project investigates the elements that impede businesses from entering the Electronic Trusted Services provision market within the European Union."

Dr Harper participated in two of the BESTS meetings as the UK representative of Thawte Certification.

[5] http://www.thawte.com/certs/cps.html (now moved to: http://www.thawte.com/cps/cps.html)

© Melanie Dymond Harper 1999. No part of this document may be reproduced elsewhere without prior permission.