On Thu, 17 Jan 2002 20:04:28 +0100 Werner Koch <wk(_at_)gnupg(_dot_)org> wrote:
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.
I should add here that:
This identifier is used with 2 purposes:
1. To identify the key
2. To provide equal security with the case where the actual key is sent [0]
The reason I replaced keyIDs with Fingerprints is that this identifier
is covered by the TLS Finished messages. This means that after the Finished
messages are sent, the parties know that the peer got a key which is identified
by the fingerprint or keyID. Since keyIDs[1] can be faked, they do not qualify
for this. If they should be added, they should be added for backwards
compatibility and only for this reason.
[0]: This is also discussed in the draft-ietf-tls-extensions-02 in the
security considerations chapter (client certificate URL extension).
[1]: I don't believe that a hash truncated to 64bits provides any security
--
Nikos Mavroyanopoulos
mailto:nmav(_at_)hellug(_dot_)gr