On 17 Jan 2002 13:07:43 -0500, Derek Atkins said:
used to present an "I can use this key" message to the other side,
which implies (to me) that the remote end would need to lookup a key
based on that number. Could you please explain how this "identifier"
That is also my understanding. The point is whether it is possible
lookup a key based on the fingerprint. I say yes because for a local
lookup you should index you keyring anyway (think about a server and
millions of users) and then it doesn't matter whether to lookup by
fingerprint or keyID. There is even no reasonable high overhead when
inserting a new key: Most keys are v4 and to get a keyID you need to
calculate the fingerprint anyway. For the few v3 keys (cf. dtype.org
for keyserver statistics) you can avoid the fingerprint calculation
but really this doesn't matter anymore.
For a lookup via keyserver there is probably a problem with the HKS
type servers but they have so many problems that they have to replaced
anyway. I am pretty sure that the NAI certserver is able to do a
lookup by fingerprint and to add this to the ALMI and cryptnet servers
will only take a few hours.
So why not using _only_ the fingerprint in TLS. IIRC we had a
discussion a long time ago to allow the use of fingerprint in the next
version of signature packets. My point is that the fingerprint is the
correct way to identify a key and that there is no need for backward
compatibilty when a new protocol is designed. Let's avoid the X.509
problem of not knowing how to cleany identify a key.
--
Werner Koch Omnis enim res, quae dando non deficit, dum habetur
g10 Code GmbH et non datur, nondum habetur, quomodo habenda est.
Privacy Solutions -- Augustinus