E-Commerce Bill Consultation Library: Charles Lindsey



Comments on the Draft Electronic Communications Bill

By Charles Lindsey 

5 Clerewood Avenue
Heald Green
Tel/Fax (0161) 437 4506

Date: Friday October 8th 1999

I am a retired Senior Lecturer in Computer Science at the University of
Manchester. Since my retirement, I have made it my business to take a
detailed interest in many activites related to the Internet, including in particular
matters connected with the authenticity and security of digital communications.

There are many features of this Bill which have attracted widespread adverse
comment, with most of which I agree. I have, however, chosen in these
Comments to address just a single issue - namely the section 10 notices, that which
they may contain, and the manner of complying with them. It is my opinion
that the Bill, as presently worded, deprives those who receive the notices of
some basic rights, whilst at the same time omitting some features which would be
of benefit to the Law Enforcement Agencies.

I start with Section 19, which defines some basic terms, and then proceed to
discuss sections 10 and 11.

Section 19.

The definitions of "signature", "key" and "protected data" in this section
give cause for concern.

In particular, it is not recognised that electronic signatures may be used
for conveying permission to perform some act. This is done by constructing some
token which conveys the permission and signing it with the private key of
the person claiming to have authority to give that permission. Examples of the
permissions that might be conveyed in this way are permissions to access
(or rather to use) some other key (whether it be an encryption or a
signature key), and for delegating authority for the giving of some permission to
someone else.

For example, the Company Accountant might be authorised to make payments
using some form of electronic funds transfer, by creating a token containing
details of the transfer and giving permission for the corporate
fund-transfer-signing-key to be used to authenticate the transfer. He would
sign the token with his own private key so that the central secure computer
that actually generated the signed transfer could check that the token came
from a properly authorised person.

More likely, he would delegate authority to make such transfers (perhaps up
to some defined limit) to some member of his staff (and revoke that authority
also, as occasion demanded). Likewise, his own authority would have been
conveyed to the central computer by some token signed by the Managing
Director, and the Managing Director's authority would have been signed by
all the other Directors, and so on - presumably the buck stops somewhere. But
notice in particular
	a) That long chains of authorizations can be built up in this way.
	b) That the keys used to sign these tokens are just the ordinary
	   private signature keys of the individuals concerned.
	c) That the tokens are not "protected information". Their content is
	   no secret; it is just that the central secure computer has been
	   programmed not to act upon them without the proper signatures.

This sort of complex system is likely to be prevalent within large
organisations where many people may have to generate signatures or to decode
documents using the Company's corporate keys, which necessitates keeping
them within some secure central computer within which the signatures or
decryptions are actually performed. Such systems will also be used by those Approved
Providers who choose to offer a Key Escrow service. In all such cases, the
corporate keys will remain at all times within the central secure computer
(they were likely even generated there) and will only be extractable from
same with extreme difficulty, if at all.

Although the keys used to sign these tokens are clearly "signature keys"
under the bill as presently worded, this matter is of sufficient importance that
this usage needs to be recognised in the text. I therefore propose that
part (c) of the definition of "electronic signature" be amended to read
as follows:

	(c) is used for the purpose of facilitating, by means of a link
	    between the signatory or other source and the data, the
	    establishment of the authenticity, or the integrity, or the
	    authority conveyed by, the data, or any combination of these

Given the strong promises made by the Government that "signature keys" would
not by subject to enforced disclosure, it is unthinkable that the Bill
should make any exception for signatures used to convey permissions as outlined
above. Nevertheless, this seems to be precisely what the Bill as currently
drafted purports to do.

Consider the definition of "key" which follows immediately after that of
"electronic signature". Firstly, the definition is circular, insofar as it
says that a "key" means, inter alia, a "key". More worrying is the use of
the word "password". Passwords, as normally understood, are not used for
encryption, nor for signatures. Rather, they are used for gaining access to
some facility. But the real sting is part (a) of the definition which
declares that a "key" can be anything which "allows access to the electronic data"
and, clearly, that covers the sort of signed token that I have described above
(it gives access to the keys stored in the central secure computer), or more
particularly the signature keys used to sign such tokens.

This, of itself, would not be of concern were it not for Section 11(2)(a)
which allows for a person to obtain access to some protected information
using a key in his possession, BUT specifically requires him to deliver up that
actual key if so "directed" in accordance with 11(3) even though that key is
likely to be a bona fide signature key being used in the manner I have
described above. This situation is quite intolerable. However, I think this
problem is best fixed in Section 10 or 11, for which see my proposals below.

Finally, the definition of "key" makes no mention of signatures, even though
the term "signature key" is used elsewhere in the Bill. So I therefore
propose that the definition of "key" be reworded as follows"

   "key", in relation to any electronic data, means any code, phrase,
	algorithm or other data the use of which (whether or not in
	conjunction with other keys)-
	(a) allows access to the electronic data, or
	(b) facilitates the putting of the data into an intelligible form, or
	(c) serves to establish the authenticity, or the integrity, or the
	    authority conveyed by, the data;

Having said that, I see no reason why the Bill needs to concern itself with
access to data at all. If there is data which is not encrypted (it is
already in intelligible form) but is inaccessible simply because the password (or
other more complex security feature) that would gain access to it is not
known, then surely all the LEA has to do is to seize the whole computer
under warrant and take it to pieces. Faced with the choice between having one's
computer seized, as opposed to giving up one's password and keeping the
computer, the average user would doubtless give up the password willingly.

So I would therefore prefer to see paragraph (a) removed from the above
definition entirely, along with the corresponding paragraph in the
definition of "protected information".

Section 10.

The drafting of this and the following section leaves much to be desired.
Basically, it fails to take account of the realities of cryptography as
currenty used, let alone of possible ways it may develop in the future. Thus
it places some unacceptable burdens on some people, whilst at the same time
failing to provide the LEAs with some of the benefits they might have
expected to have.

The major failings I will deal with under Section 11, but in the meantime
there are various lesser matters which affect Section 10, the first of which
is the confusing terminology whereby the word "person" is regularly used,
even within the same paragraph, to refer to:
	(a) The "person" who has acquired a copy of the protected data by some
	    statutory or other means (subsection (1)).
	(b) The "person" with the appropriate permission to serve a notice.
	(c) The "person" upon whom the notice has been served.

I propose that most of the confusion can be removed by using the word
"officer" to cover case (b), both here and in Schedule 1, and my further
proposals below are worded on that assumption.

subsection (2):

This needs to recognise that there may be several keys involved with access
to the protected data, that they may be in the possession of several persons,
and that some of them may need to be derived by possibly complicated processes.
My proposed ammendments are

p10 line 1	any person => any officer
    line 2	a key to the protected information =>
		a key or keys to the protected information, or the means
		wherewith to derive such keys
    line 3	any person => any person or persons
    line 4	person => officer
    line 5	possession of the key => possession of such a key
    line 5	disclosure of the key => disclosure of that key

subsection (3):

Paragraph (a) seems to envisage notices being delivered by electronic means,
and seems to be based on the idea that "proof of posting" is equivalent to
"proof of delivery". That is grossly unfair. It must be possible for the
officer to prove that the notice has been received in much the same way that
the serving of paper documents currently reuqires proof.

Another problem is the time allowed for compliance with the notice. It is no
use the officer serving the notice and saying "right, you now have 5
minutes, or you will be charged under Section 12". For the reasons I have outlined
earlier on, it may take hours, or even days, to comply in some situations.
My proposed ammendments are

p10 line 10	given => given and received
p10 line 12	person => officer
p10 line 14	to be made =>
		to be made, such manner and time being reasonable having
		regard to the technical difficulties of performing the

It is not stated how the noticed is supposed to identify the required key,
and this is particularly important in the case where several keys may be
involved, such as an asymetric private key and a session key. The only way to identify
the key is to provide the person with the protected data (if he does not
already have it). Or, if he does not have it and the officer does not want
him to be in a position to retrieve the plaintext, then at least a
sufficient part to enable the session key to be extracted. I would therefore propose an
additional paragraph (d)

	(d) must, unless the protected information is already in the
	    possession of the person receiving the notice, incorporate that
	    protected information; or at least a sufficient part of it to
	    enable the person to identify all of the keys involved; or else,
	    in the case where the notice refers to information likely to come
	    into the possession of any person in accordance with paragraphs
	    (a) and (b) of subsection (1), sufficient information to identify
	    the class of protected data to which the keys are, or will be,

subsection (4)

p10 line 17	person => officer

subsection (5)

This is an important safeguard, which has been guaranteed by the Government.
Nevertheless, there exist keys (notably PGP keys generated by earlier
versions) which the user now uses only for signature purposes, but had once
used for encryption many years ago. Or since, with some keys, it is
impossible to prevent them from being used for encryption, someone might send him a
message encrypted with it, so as to embarass him. It is hard to see how to
deal with this entirely, but at least it should be incumbent upon the LEA to
prove that a supposed signature key was in fact being used for encryption,
and for sure the fact that it had only been so used long before the present
circumstances arose should not provide an excuse for the LEA to demand a
signature key, as the present wording clearly allows. I propose, at the

p10 line 24	has not in fact been used for any other purpose =>
		is not in fact currently in use for any other purpose

There is a further problem in that private keys (whether for signature or
encryption) are customarily stored on the user's computer in encrypted form,
and he needs to provide a "passphrase" in order to decrypt them whenever he
needs to use them. It was clearly the intention of the Government's
guarantee that a user should not be compelled to divulge either his private signature
key, or the passphrase that protected it. Nevertheless, in the case where
the (passphrase-encrypted) private signature key has come into the possession of
the LEA (by seizure of the computer under warrant, for example) the Bill, as
currently drafted, would allow the officer to demand the passphrase. For the
encrypted signature key is clearly "protected data", and hence the officer
can demand the key to put it into intelligible form (i.e. the form in which it
could then be used to sign documents). Clearly, this is intolerable.
Furthermore there is the loophole which I identified above when discussing
signed tokens. I therefore propose an extra paragraph (c):

	   ...; or
	(c) where the protected information to which the key relates is or
	    contains a further key which is not itself the subject of this or
	    any other notice.

Section 11.

The wording of this section is convoluted and full of double negations, it
contains a right to direct that actual keys be provided even when the person
is willing and able to provide timely decryption into intelligible form,
with absolutely no restrictions on the exercise of that right, and it is couched
in terms that are only applicable to the simplest and most straightforward
cases of encryption, such as were commonplace 10 years ago, but bear no
resemblance to the sophisticated and complex systems which are encountered today, and
still less to what may be found in the future. Thus this section does not
provide the LEAs with the powers that they actually need, not does it
provide the owners of the keys with the protection that is their due.

It cannot be overemphasised how serious it would be for a large undertaking,
such as a bank, to have its main corporate encryption keys seized. The costs
to the Bank would run into millions. It is useless to argue that the seized
keys would be in safe hands as set out in Section 15. No corporate executive
in his right mind would place any credence in such promises, especially
given the knowledge of the collusion of the UK in the Echelon project. But this is
not all bad news. A bank faced with the prospect of losing its keys would be
willing to fall over backwards in an effort to provide all assistance to the
LEA short of actual disclosure. The Bill should be worded so as to give the
LEAs full benefit of such willingness.

The basic fallacy of the present Bill is that it keeps speaking of "the" key
to the data, and fails to recognise that
	(a) There may exist several alternative keys ANY ONE OF WHICH would
	    suffice to access the protected information. This arises
	    particularly where the information is first encrypted with a
	    transient "session key", which is then itself encrypted with the
	    user's private key. Since the compromise of the latter would be
	    disastrous for the user, he must have the absolute right to
	    choose to disclose only the session key. Other cases of multiple
	    alternative keys arise when an encrypted communication is
	    addressed to several people.
	(b) There may exist sevral keys ALL OF WHICH (or, at least, several of
	    which) are required in order to access the protected information.
	    This usually arises when some sensitive piece of information (such
	    as an important corporate key that would, for example, unlock the
	    central secure computer) is divided into several parts, each part
	    being deposited with a different person for secure keeping. If,
	    for example, it were split amongst 8 people, then it could be
	    arranged so that the bringing together of any 6 of them would
	    suffice to access the protected information. Techniques for doing
	    this securely have been known for many years, though they are not
	    yet as widely deployed as they should be.

Now it would be foolish for the wording of the Bill to get involved in
detailed technicalities such as "session keys". Nevertheless, it needs to be
worded in such a way as to encompass all the above possibilities in as
general a manner as possible. I therefore offer the following wording for your

11.-(1) Subject to the exception listed in subsection (2), a person required
by a section 10 notice to disclose a key to some specified protected
information, or to protected information of some specified class may, in
order to satisfy that requirement, and at his choice, either
	(a) where there exists only a single key matching the requirement,
	    disclose that key; or
	(b) where there exist several keys, any one of them being sufficient
	    to match the requirement, disclose any such key; or
	(c) where there exist several keys needing to be assembled together in
	    order to match the requirement, disclose such of them as are in
	    his possession; or
	(d) where there exist several keys needing to be assembled together in
	    order to match the requirement, make arrangements with other
	    persons who have also been given section 10 notices, and are in
	    possession of such of those keys as he does not himself possess,
	    to derive from them a single key which matches the requirement,
	    and then disclose that key; or
	(e) where the notice specifies a class of protected information likely
	    to come into the possession of any person persuant to subsection
	    (1) paragraphs (a) or (b), make arrangements for keys to specific
	    items of protected information to be disclosed in a rapid and
	    timely manner upon being presented with those items, or at least
	    with sufficient parts of them, by the officer who gave the notice;
	(f) where he is in a position to disclose any key or keys in
	    accordance with paragraphs (a) to (e) above, and the protected
	    information is already in an intelligible form but cannot readily
	    be accessed without that key or keys, use that key or keys to
	    access the protected information and then disclose it in place of
	    that key or keys, provided he does so by the time before which he
	    would otherwise have been required to provide that key or keys; or
	(g) where he is in a position to disclose any key or keys in
	    accordance with paragraphs (a) to (e) above, and the protected
	    information cannot readily be put into an intelligible form
	    without that key or keys, use that key or keys to put the
	    protected information into an intelligible form and disclose that
	    intelligible form in place of that key or keys, provided he does
	    so by the time before which he would otherwise have been required
	    to provide that key or keys, and provided he is able to
	    demonstrate that the form disclosed corresponds to the protected
	    information provided.

Observe that I have distinguished (f) (access to unencrypted information
protected by some lock, and which I have already suggested should be
excluded from the bill anyway) from (g) (decryption, or putting into
intelligible form).

Now to the matter of the right of the LEA to demand keys even when decrypted
information is on offer. I oppose this also, but here is the wording that
would apply if it is needed. Note that I have carefully excluded case (f)
above - if the data itself is offered, why on earth should the LEA require
the key (in this case the password) as well?

11.-(2) A person required to disclose a key to protected information may not
avail himself of the option instead to put it into intelligible form as
provided in paragraph (g) of subsection (1) if
	(a) the relevant authority who for the pourposes of Schedule 1 granted
	    the permission for the giving of a section 10 notice in relation
	    to that information, or
	(b) a person whose permission for the giving of such a notice in
	    relation to that information would constitute the appropriate
	    permission under that Schedule,
has given a direction that the requirement can be complied with only by the
disclosure of the key itself. Such a direction shall not be given unless
there are exceptional and cogent reasons whereby disclosure of the protected
information in intelligible form would vitiate the whole purpose of serving
the notice.

That last sentence (which could perhaps be worded better) is intended to
make it clear that such directions are not to be given by those with the relevant
authority (that is the Secretary of State, Judges, etc) as a matter of
routine, but only reserved for exceptional situations (which the Tribunal
might want to be explained to them afterwards). I find it hard to imagine a
circumstance where this would apply, expect perhaps where the person on whom
the notice was served was himself under suspicion, and the LEAs has come
into possession of encrypted communications which, for some reason, had not been
delivered to that person, and which they did not want that person to see. It
all sounds pretty far fetched to me. Parliament would certainly need to be
convinced of the necessity for this if this feature is to remain in the

Section 12.

This and the following section contain so many violations of basic humans
rights, notably the presumption of innocence until proved guilty, and is in
such blatant disregard of the European Convention on Human Rights (shortly
to be enacted into British Law) that the mind boggles. How Ministers could
stand up in public and deny these breaches beggars belief.

However, these matters have already raised such a furore that I have no
doubt that other commentators will have addressed them fully.

Version: PGPfreeware 5.0i for non-commercial use
Charset: noconv



The Foundation for Information Policy Research is registered in England and Wales under the Companies Act 1985 as a private company limited by guarantee (No.3574631). Application for charitable status is in progress.

Last Revised: October 17 1999