From: Theodor.SCHLICKMANN@bxl.dg13.cec.be
To: <cypherpunks@algebra.com>
Message Hash: 37ff2f47099f4f7b335b6cfab065561d02a0983fc5a43fecf8b914fdb37173b7
Message ID: <WIN2359-970512134423-1E44*/G=Theodor/S=SCHLICKMANN/OU=BXL/O=DG13/PRMD=CEC/ADMD=RTT/C=BE/@MHS>
Reply To: N/A
UTC Datetime: 1997-05-12 13:59:31 UTC
Raw Date: Mon, 12 May 1997 21:59:31 +0800
From: Theodor.SCHLICKMANN@bxl.dg13.cec.be
Date: Mon, 12 May 1997 21:59:31 +0800
To: <cypherpunks@algebra.com>
Subject: Copy of: UK TTP Paper - For Your Information
Message-ID: <WIN2359-970512134423-1E44*/G=Theodor/S=SCHLICKMANN/OU=BXL/O=DG13/PRMD=CEC/ADMD=RTT/C=BE/@MHS>
MIME-Version: 1.0
Content-Type: message/rfc822
To: Joep.VAN-DER-VEER@DG15.cec.be, Theodor.SCHLICKMANN@BXL.DG13.cec.be, Konstantinos.PAPANIKOLAOU@BXL.DG13.cec.be, Christine.SOTTONG-MICAS@DG15.cec.be, Detlef.ECKERT@BXL.DG13.cec.be, Andrea.SERVIDA@DG3.cec.be, Richard.SWETENHAM@LUX.DG13.cec.be, Telmo.BALTAZAR@SG.cec.be, Giuseppe.CASELLA@DG3.cec.be
Subject: UK TTP Paper - For Your Information
From: David.HERSON@BXL.DG13.cec.be
-----Original Message-----
From: Hendon David
Sent: Friday, May 09, 1997 3:06 PM
To: Non Receipt Notification Requested; Non Receipt Notification Requested
Subject: Open Reply to Charles Lindsey's Open Letter to the DTI
cc Brian Gladman - please post to UKCrypto
Dear Mr Lindsey
OPEN REPLY TO THE "OPEN LETTER TO DTI" ON THE TTP CONSULTATION PAPER
First of all let me thank you for your letter of 24 April on the DTI
Consultation Document, and also apologise for this rather late reply. As
you can imagine the last couple of weeks have been rather busy for
Whitehall Departments.
I am glad you wrote, as it gives me an opportunity to clarify a number of
issues which have arisen in both the various Usenet newsgroups and also in
the responses we have received to the Consultation Document. Let me first
set the Consultation Document in context.
The Document, as the Introduction to it hopefully made clear, is an outline
of how the previous Government's policy might be implemented. It follows
on from the announcement last June on the provision of encryption services.
Whilst drawing up the Document we took careful notice of the various
reactions we had received to that announcement. Unfortunately, there were
not many. Since the Consultation Document was published, a new Government
has been elected. Ministers have not yet had the opportunity to consider
this subject. It therefore follows that what is said below represents only
the current view of officials from DTI and other Government Departments.
I will take your questions in order:
1. Authentication of public keys by private individuals:
Of all the issues you raise this has perhaps caused the most concern to
readers of the Consultation Document. So let me confirm the position we
take. We do not have any intention to impose licensing conditions on
individuals who through whatever action, certify the public keys of another
individual through the basis of personal knowledge or friendship. It
would, however, be possible (and this is why the Paper is perhaps ambiguous
on this point) for an individual (as opposed to an organisation) to carry
out a certification process as a service using knowledge (to guarantee
authenticity) gained by conventional means (such as passports etc). It
would also be possible for an individual to systematically certify the keys
of a large number of individuals through "hearsay" knowledge. Such
arrangements, we believe, should be subject to licensing.
2. Requirement to escrow private keys:
Again this is an issue which has been commented on frequently in the
Newsgroups. As further discussed in the answer to question 4, we can
confirm that we do not propose that the user be required to escrow his
private signature key (however generated) with a TTP. In addition a user
is clearly at liberty to generate his own key pair for confidentiality; in
such circumstances we are not requiring the private key, of this pair, to
be located with a TTP. If, however, the TTP either generates the
confidentiality key pair for a user, or, for example, certifies a
self-generated public key for confidentiality, then escrow of the
associated private key would be required under our proposals. Everyone
should recognise that this is a compromise under which we acknowledge that
a proportion of confidentiality keys will not be accessible via the warrant
process because they have not been escrowed.
3. Freedom to publish keys and certificates:
We can confirm that the proposals do not seek to licence an individual or
organisation that simply provides a location where others' public key
certificates or public keys can be published. This, however, is on the
understanding that the individual, or organisations do not (themselves)
take steps, or provide a facility for others, to authenticate that public
key or associated certificate.
4. Exemption of signature-only private keys from disclosure under warrant:
You have correctly identified this question as going to the heart of the
"legal access" proposals we have made. And of course you are right in
identifying the need for the Government to explain how its policy
objectives are to be met in this area. But we have been entirely
consistent in pointing out, both in the Consultation Document and in other
public fora, that private keys for signature play no part in the law
enforcement elements of these proposals. It would be completely wrong and
counter-productive to law enforcement objectives for the authorities to
have the capability to interfere with the integrity or authenticity of a
communication.
You invite a technical and detailed explanation of how we intend to cope
with the ability of the RSA algorithm (and others) to issue a key pair that
can be used both to ensure the integrity and confidentiality of a message.
I think the answer, at least at this stage, is that there probably is no
such technical method (since we don't intend to restrict the choice of
algorithm) to prevent this. In terms of procedure, however, I think there
is a clear distinction between the use of a key-pair for confidentiality as
opposed to signing. As we understand the issue it is a requirement (or at
least accepted practice) that the public key certificate identifies the
purpose for which it is to be used. In other words the TTP (acting as a
certification authority) will certify the public key, of an individual, for
a particular purpose. Therefore if it certifies a public key for signature
it would not require the deposit of the associated private key; while if
it certified a key for confidentiality then it would. It follows, I
believe, that if a user then used a "signature" key for confidentiality it
would be doing so outside of the terms of the certificate. It would
therefore be unwise, in normal circumstances, for the user to do this as it
would mislead his potential counterparts. Now I appreciate that such a
scenario could allow the sender and receiver (both using certified
signature keys) to use the TTP network for encryption purposes without the
possibility of key-recovery. This is, therefore, clearly something we
would need to look at carefully. But in many respects, I would argue, it
is little different from two users using encryption outwith the TTP network
entirely (eg PGP); a scenario we accept will take place whatever we wish or
do.
I trust the above is helpful to you. I am sure it has not answered all of
your questions or even fully the ones you posed. There is a long way to go
yet. We will, as indicated, ensure that a summary of the responses we
receive is published after the period of consultation finishes. By the
way, the consultation period ends on 31 May. I have seen some speculation
on the Internet that comments should be sent well ahead of this date to be
considered by DTI. This is not the case. All responses, email or letter,
sent on or before the 31 May will be considered.
Yours sincerely
David Hendon
Communications & Information Industries Directorate
DTI
9 May 97
Return to May 1997
Return to “Theodor.SCHLICKMANN@bxl.dg13.cec.be”
1997-05-12 (Mon, 12 May 1997 21:59:31 +0800) - Copy of: UK TTP Paper - For Your Information - Theodor.SCHLICKMANN@bxl.dg13.cec.be