11 March 1999

Date: Tue, 9 Mar 1999 17:07:27 GMT
From: Charles Lindsey <chl@clw.cs.man.ac.uk>
To: UKcrypto@maillist.ox.ac.uk
Subject: Comments on the DTI document

The DTI proposals are clearly a considerable improvement on anything we
have seen before. More importantly, it is clear that their understanding
of cryptographic issues has advanced considerably since then (I think
this list can take some of the credit for their education), to the
extent that they now seem to be asking the right questions, and even
giving many of the correct answers.

Nevertheless, the details still need to be examined carefully, and there
are some suspicious examples of double-speak which might leave room for
things to change in the wrong direction come the legislation. So here
are my own comments, some of which may form part of my eventual
submission to them.

1. Key Generation.

This is, I think, the biggest flaw in the present document. In #38,
under "Illustrative Examples Of Cryptography Services":

	Key Generation: Key generation is a critical part of the process
	whereby the key pair (both public and private) is generated for
	the issue of a certificate.

So they clearly recognise the criticality of key generation, yet they
still imagine that it will be the normal situation for CAs and other
TSPs to be generating keys! The mind boggles! And yet they truly seem to
believe this.  Under Annex A(II):

	Generation of Key Pair: A provider will need to submit details
	of how an asymmetric key-pair is generated and, if appropriate,
	delivered to the client. If the key-pair is to be
	clientgenerated then details of the process used will need to be
	An applicant must provide details of the mechanism it uses to
	ensure that the private signature key is only known to the
	client on issue.

And this is part of an attempt to ensure that CAs follow some sort of
'best current practice'? See also #44.

Let us be clear what 'best practice' is.

Key Pairs (especially for signature) MUST be generated by the client,
preferably on his own equipment (or on board his recently-purchased
smart card), and ideally on his own laptop in the middle of a large
field away from all possibility of Tempest surveillance. Whilst one
MIGHT allow him to use a program provided by the CA for the purpose, the
algorithm used MUST be in the Public Domain, and he MUST have the choice
of using a program obtained from elsewhere. Indeed, the normal situation
should be that he generates his key BEFORE bringing it to the CA.
Moreover, he might submit the same key to more than one CA, and when the
certificate expires he might take it to a different CA for renewal
(perhaps for a smaller fee). Moreover, it MUST be impossible for any Bad
Guy that sees the public key to be able to tell by whom or with what
program it was generated (for if you know what program generated it, you
perhaps know what Trojan Horses were embedded in that program).

If a CA should offer to generate a key and deliver it to you, then that
MUST be grounds for immediate withdrawal of that CA's licence.

There is the related problem of ensuring that the algorithm used for
generating the key is above suspicion. This comes in two parts: using an
adequate means of generating random numbers, and ensuring that it
contains no Trojans. Annex A(II) seems to recognise this:

	Technical Assurance: A provider will be expected to provide
	evidence, if appropriate, that the systems used for generating
	key pairs and storing its own private key has been independently
	assessed (e.g.  through the issue of an ITSEC or CC Certificate)
	in terms of security assurance.

(well, maybe that is addressed at generating its own keys, which
certainly must be beyond reproach). And then, further on:

	User signature generation products: Although not a condition of
	the licence, a client of a licensed Certification Authority will
	be required to use an "approved" signature generation product to
	take advantage of full legal recognition (see page 12). Licensed
	Certification Authorities will be required to supply information
	on products which have been "approved".

That "approved" is worrying. Who is to give "approval". Footnote 13 on
p12 makes vague reference to "discussions on the EU Electronic
Signatures Directive". This needs clarification. To my taste, the best
form of approval is that given by public scrutiny of published
algorithms, but that is not much help in ensuring that a smart card has
no Trojans within it. But, IMHO, I would rather have a signature
generated independently by a less-than-perfect program than one
generated on my behalf by a CA using the pig in his poke.

I have made a big issue of this. It IS a big issue. The present document
is not "technology neutral" in this regard. Indeed, it positively
fosters a regime where the Government could actually control
cryptography by misusing the licensing and approval mechanisms. I am
sure this is not the Government's intent, but that is not enough. It
should be seen not to be the Government's intent.

2. Legal recognition of signatures.

I only spotted this one when composing the previous section. Look at

	The intention of this is to give parties relying on an
	electronic signature, backed by a certificate from a licensed
	Certification Authority and using an "approved" signature
	creation device, a high degree of confidence that the signature
	is what it claims to be.

So far so good:

	Such a degree of legal recognition will also apply where a
	"qualified certificate" is used to back up an electronic
	signature created by an "approved" signature creation device.

And there's the "gotcha"! A qualified certificate (from an unlicensed
CA, perhaps) is OK, if the Court believes it, but it still must be
signed by 'an "approved" signature creation device'. Actually, this
looks like a problem within the EU Electronic Signatures Directive,
rather than the DTI document.

Who cares how the document was signed? The important question is whether
it was verified by "an approved signature verification device". There is
no way that a document could be forged so as to fool such a verifier
whether by accident, or by using an unapproved signature device. The
only way to produce a forgery is to use too short a key, or a key
_generated_ by an unapproved device (complete with Trojan), or to have
possession of the private key.

3. Double-Speak.

Nice bit in #36:

	Businesses are increasingly recognising the importance of being
	able to recover critical data, which staff may have encrypted,
	or the text of messages ... Providers of confidentiality
	services are, therefore, encouraged to make the recovery of keys
	(or other information protecting the secrecy of the information)
	possible through suitable storage arrangements ...

Followed by #37:

	The widespread deployment of such technologies would also help
	law enforcement, by allowing law enforcement agencies to recover
	encryption keys under strictly regulated procedures.

Talk about putting the cart before the horse :-) .

But the worst is in Footnote 17:

	An alternative to the use of Trusted Third Parties (TTPs) and
	key escrow is the use of encryption products which support key
	recovery, also known as key encapsulation, (confusingly key
	recovery can be used as a generic term to cover both key storage
	or "key escrow", and key encapsulation; we only use it in the
	narrower sense in this document).  Such commercial encryption
	products, which are already being used in the US, can
	incorporate the public key of an agent (usually a company) known
	as a Key Recovery Agent (KRA). This allows the user of such
	products to recover their (stored or communicated) data by
	approaching the KRA with an encrypted portion of the message.
	Lawful access to the keys (which are likely to be different for
	each message) can also be granted if a written authorisation is
	served on the KRA. In both cases, namely access by the user or
	by law enforcement, the KRA neither holds the user's private
	keys, nor has access to the plaintext of their data.

As they say (and confirm in the glossary definition) 'confusingly key
recovery can be used as a generic term to cover both key storage or "key
escrow", and key encapsulation"'. And who is doing the confusing? Why
the DTI of course, by taking a term with an admittedly ambivalent
meaning and redefining it to suit their own convenience. The proper term
for what they describe is "plaintext recovery" or, to use the term most
often applied, "GAK". But, of course, they couldn't say that, could

And even what they are trying to say is wrong. If the Company wants to
recover its encrypted files after an employee has left, why does it need
the extra key to be held by an external KRA? Why not hold it internally?
There is a feature in PGP 5.5 to do this job (much maligned by those who
wish to misunderstand it) but it does not involve any external KRA. Does
anyone know of any products that actually operate in the manner

4. Licensing.

The decision to use OFTEL as the licensing agency does not fill me with
overwhelming confidence :-( . But who else could they have chosen? The
Data Protection Registrar, perhaps? There really is no existing
Government Body with the necessary expertise (well, there is, but we
don't talk about that one, do we?).

So the real question is "How is OFTEL to be educated in the necessary
skills and knowledge to fulfill its task"? I am not aware that they
currently employ any professional cryptographers, but clearly they will
need to do so.

There seems to be some intention to involve industry. That is probably
good, but it needs to be spelled out in more detail. Essentially, I
think what we want is a Licensing Board, composed of Government and
Industry representatives - a Quango that is seen not to be totally under
Government control. It must also be made clear that its duty is towards
the users of cryptography, not towards those who supply it. In other
words, it should issue licences and approve products purely on their
technical merit, and without regard to where they came from (as we know,
the best cryptographic products actually arise from cottage industries).
The acid test would be whether it would be possible for GPG to obtain
approval as a signing tool.

In fact, a specific exemption from approval fees for products to be put
in the Public Domain would be no bad thing.

5. Export controls.

Look at #47. They let the horns show through their cap for an instant
:-( .

6. Law enforcement.

Well their examples are bogus (or rather inapplicable) but there is
indeed a problem to be faced. The idea seems to be that anyone who holds
a key can be required, by warrant, to provide assistance to the LEAs.
Fair enough; I think that is accepted, but it is the details that have
to be looked at. Look at #58:

	This means providing a power for lawful access to encryption

But what they actually want is access to plaintext. The encryption key
is just one way of obtaining it. What they need to distinguish here is
access to
	a) Private keys
	b) Session keys
	c) Plaintext
Each or which may be appropriate in some circumstances. But the total
lack of all mention of "session keys" is a notable omission from the
document. Look at #63:

	The Government believes it is necessary to establish a new power
	to allow the police to require disclosure of encryption keys ...

But what they should actually want is whichever of the three is
appropriate to the circumstance. Look at #69:

	The written notice will specify the keys or material required to
	be disclosed. It will be for an authorised officer to decide,
	given the circumstances of a particular case, whether to order
	the production of specified material in a comprehensible form
	(e.g. the plaintext of a document) or order disclosure of the
	relevant confidentiality key.

And there it is! It is the "officer" who decides! That is not good
enough. To require delivery of a Private Key, from a possibly innocent
party, is going to do untold damage to that party (or to those on behalf
of whom that key is held) because it can enable access to communications
way beyond those covered by the Warrant. Yes, there are the usual
incantations against unlawful usage of the key by the authorities, and
about destruction of the key when the investigations are complete, but
suppose you are a large, respectable, (and innocent) Bank. Suppose a
private key has been seized that covers a substantial amount of your
incoming traffic. Would you trust such assurances?  Well, would you?

No! The party on whom the warrant is served MUST be given the option of
providing the private key OR of providing session keys generated with
it. If this means that the party (the Bank) has to set up a service to
provide session keys in return for the headers of encrypted
communications within milliseconds, then so be it.

Again, the party MUST be allowed the option of providing plaintext to
the Officer. This may not be so simple, because perhaps the Officer does
not want the party to see the plaintext, and moreover the party would
have to convince the Officer that the plaintext he delivered did indeed
derive from the cryptotext provided; and that really involves disclosure
of the session key.  So I think that, in either case, it is likely to be
the session key that should normally be handed over, unless the
_party_concerned_ elects otherwise.

Now look at #80:

	The proposals described above rest on the assumption that, by
	serving an appropriately authorised written notice, it will be
	possible to decrypt communications and stored data. This will
	normally be true where the notice is served on the individual in
	control of the encryption process.  ^^^^^^^^^^

Is this a typo, or have the DTI not YET realised that you have to serve
the warrant on the man who can _decrypt_ the communication?

7. Warrants.

#88 speaks of "timeliness" of the decryption process. Elsewhere, the
document speaks of the need for the restrictions to be "proportionate".
These issues are related. If you are following a money-laundering
operation, then milliseconds are important. If terrorists are planting a
bomb, then you are concerned about minutes. To catch drug runners, you
need your information within hours, and when tracking paedophiles, it
does not really matter if you have to wait days.

So a warrant SHOULD indicate the urgency appropriate to the particular
case, and not demand faster or more immediate compliance than is
justified by the circumstances.

The regulation must also take account of the fact that, even where an
important key is escrowed with TTPs, it is likely that it will have been
split into, say, four parts such that any three of them can be used to
reconstruct the key, and the four parts deposited with four different
TTPs. This is "current best practice" and so must be regarded as normal
(remember, these proposals are "technology neutral"). Indeed, a TSP who
advises any practice other than this in the case of an important key of
a large corporation deserves to have his licence revoked, anyway.

It should be possible for the four TTPs involved to be able to set up
means for producing session keys in a timely manner when served with
proper warrants, but do not expect them to be able to set up such a
facility in a short time, certainly not at 2a.m. on a Sunday morning
when at least two Directors of each TTP involved would have to be called
to authorise the setup (any TTP who permitted operational staff to act
upon such warrants would not be worthy of licensing in any case).

I note that several places (e.g. #67 and Annex A(III)) explicitly use
the word "written" in connection with warrants. This is good (assuming
it means what it says). But there is no mention of how quickly such
warrants would have to be executed (recall the "instantaneous" execution
of electronic warrants envisaged by the previous proposals).

I believe that this should be no faster that that required under the
present IOCA, or no faster than 12 hours, whichever is the greater, the
reason being that there MUST be time to go before a Judge in Chambers to
attempt to show that the warrant is unlawful.

And finally, please can someone explain to me how the LEAs are supposed
to know who (or which TTP(s)) holds a particular private key that they
might happen to be interested in.

8. Alternatives to escrow.

In #87 we find:

	A proportion of electronic commerce activity will occur between
	individuals and corporate organisations. Where this involves
	serious criminal activity, law enforcement agencies may need
	access to communications between serious criminals and corporate
	organisations (e.g. internet shopping, purchasing airline
	tickets etc.). However, law enforcement agencies would be
	content to seek the co-operation of
	the legitimate corporate organisation where this is necessary.

Well, I would rather see "should" in place of that "would". The
corporate organisations are likely to be the innocent parties in this.
Moreover, they are going to have to be relied upon not to "tip off".

However, there is another possibility available in the case where the
corporate organisation is a Bank, which will be the common case. There
is already a power under some Act (I don't know which, but it is
certainly not PACE or the IOCA) for details of bank accounts and
transactions within them to be inspected by LEAs, under suitable
warrants. This power could easily be extended to the provision of
instant electronic access to all transaction in designated accounts,
under an appropriate warrant.

This would actually provide the LEAs with _more_ than they would get by
decrypting specific communications, because they would automatically get
to see ALL transactions to that account (like being able to listen to
both sides of a conversation) without the necessity of having to tap any
communications, or even of having to work out which communications would
need to be tapped.

And it would be better from the Banks' point of view (albeit expensive
to set up) because it would save them the embarrassment of having their
valuable private keys disclosed.

9. Content of certificates.

This proposal is supposed to be technologically neutral. Therefore it
cannot dictate any particular format for certificates, etc. That is a
job for industry and the standardization bodies.

Now we have, in Annex A(II):

	* a unique certificate number;

Would a hash of the certificate suffice?

	* an unambiguous statement that the certificate must not be used
	to validate a key being used to secure the confidentiality of

I have no objection to that in principle (there are obvious ways of
getting around it, so it is really just a political statement). But it
might not be technologically possible within a given encryption system.
Therefore, it needs the addition of:

	"or alternatively, the key certified must be self-evidently a
	signature-only key."

That would then be suitable for Open-PGP, where that information is
carried in the key rather than in the signature. Note also that, if
asked to sign an Open-PGP key that included both a (primary) signature
key and a (secondary) encryption key - this is the normal PGP case -
then the CA could return a certificate computed over only the primary
portion of the key.

10. Liability.

#44 raises the question of the liability of CAs if they should
inadvertently grant certificates to the Bad Guys. The issues seem to be
well covered, so I would just wish to emphasise that the primary
liability of the CA is to the _third_party_ who relies on the
certificate, even in the case where he has paid no consideration for it.
Since this is a departure from the normal law of contract, it will
indeed require special legislation.

11. Spamming.

The section on spam (#28) is an interesting (though important) red
herring.  May I suggest that we submit comments upon that section
separately from whatever comments we submit regarding encryption.

12. And finally.

Observe Footnote 3:

	For the purposes of this document, providers of cryptography
	services are described as Trust Service Providers.  A TSP may
	provide one, or more, cryptography services including acting as:
	a Certification Authority (see footnote 4), a Trusted Third
	Party (providing confidentiality services) or a Key Recovery
	Agent (see footnote 17).

Observe that "one or more". That is the big concession that has been
made in the last few months. Watch it carefully to make sure that it

Charles H. Lindsey ---------At Home, doing my own thing------------------------
Email:     chl@clw.cs.man.ac.uk  Web:   http://www.cs.man.ac.uk/~chl
Voice/Fax: +44 161 437 4506      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9     Fingerprint: 73 6D C2 51 93 A0 01 E7  65 E8 64 7E 14 A4 AB A5

To: ukcrypto@maillist.ox.ac.uk Subject: PKI and law enforcement Date: Wed, 10 Mar 1999 11:10:46 +0000 From: Ross Anderson <Ross.Anderson@cl.cam.ac.uk> So the policy is supposed to build consumer confidence in e-commerce and help law enforcement. Two comments: (1) It certainly offers a big carrot to commerce - particularly to banks and merchants - in that it will limit their liability. At present, if I use a credit card to buy something on the net and get ripped off - whether the goods are shoddy or extra transactions get billed, it doesn't matter - then I have a claim against the card issuer under the Consumer Credit Act, and the issuer can recover costs and damages from the merchant. Under the proposed arrangements, if approved digital signature are used to make such transactions, then signatures made with my key will be presumed valid even if I didn't make them, and the bank has its liability limited. So bankers win and consumers lose. Stand by for a dirty great rush to deploy SET in place of SSL :-) (2) I fear the proposals will actually harm law enforcment. Secure communication is often easier if at least one of the principals has a certificate. At present only banks and merchants have them; so they can can communicate securely with individuals using SSL, but for individuals to talk to each other they need to fiddle around with PGP or whatever which is too much hassle for most. (I am ignoring embedded apps where the customer keys can't sign arbitrary content.) However if the DTI proposals succeed, we will end up with a public key infrastructure of certified keys which are held by users and which can sign arbitrary content. This is not actually needed for e-commerce; we could happily muddle on using credit cards and SSL. But the DTI will have removed the main brake on deploying secure user to user communications. Sure, someone will have to actually write the `unclicensed' software that bootstraps off the PKI, but there will be no shortage of willing coders! The intelligence community now considers Clipper to have been a bad mistake - had the NSA not panicked at the the AT&T crypto phone and persuaded them to incorporate it, the 3-DES version of the phone would have sold a few hundred units and then been abandoned. Crypto would still be an obscure subject of interest to a couple of hundred mathematicians. I predict that PKIs will be the same, and if I were Director GCHQ I would be doing everything in my power to see to it that only responsible companies got public key certificates. The spooks' underlying problem is that they have invested enormous amounts of time and effort persuading the pols that `something must be done' about cryptology. However all the practical proposals they have come up with just look set to make the problem worse. Ross
Date: Wed, 10 Mar 1999 15:24 +0000 (GMT Standard Time) From: hcorn@cix.co.uk (Peter Sommer) Subject: duncan campbell@csrc/lse: March 16 To: ukcrypto@maillist.ox.ac.uk Computer Security Research Centre Public Security Colloquia 16 March 1999 Tuesdays LSE Clement Building Room D602, 1700-1900hrs Global information surveillance: Intelligence and law enforcement planning and capabilities Duncan Campbell Duncan Campbell will report on and discuss his current work for the European Parliament on such systems as Echelon and proposed legislation / mutual assistance arrangements as Enfopol and the US Communications Assistance to Law Enforcement Act.  On the back of e-commerce, the world's largest intelligence-gathering and law enforcement agencies have increased their demands for access to real-time surveillance facilities.  What is possible now,  what might be possible in the future,  what justification can be made,  and what controls on this activity should we be seeking? Members of the public may attend free of charge but must pre-register by e-mail to csrc@lse.ac.uk.  As this is work in progress thee meeting will take place under Chatham House Rules;  there will be a free exchange of ideas but the meeting cannot for the moment be reported in the press.  The LSE Clement Building is on the Aldwych, London WC2 between the Law Courts and the south end of Kingsway;  there is a large hanging white sign on the outside. Future Programme details:  http://csrc.lse.ac.uk/Colloquia/colloquia1.htm Enquiries: 0171 955 6197 (voice-mail service) This year's colloquium series is made possible through the kind assistance of Deutsche Bank |->   Peter Sommer   --------------------------------------------->| |->   hcorn@cix.co.uk   P.M.Sommer@lse.ac.uk  -------------------->| |->   Academic URL:  http://csrc.lse.ac.uk/Sommer/sommer.htm  ---->| |->   Commercial URL:  http://www.virtualcity.co.uk  ------------->| [See also Duncan Campbell's Echelon reporting: http://jya.com/echelon-dc.htm]