Re: Fw: [ietf-tls] using openpgp with tls

Nikos Mavroyanopoulos <nmav@hellug.gr> Fri, 18 January 2002 14:56 UTC

Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13466 for <openpgp-archive@odin.ietf.org>; Fri, 18 Jan 2002 09:56:38 -0500 (EST)
Received: by above.proper.com (8.11.6/8.11.3) id g0IEf6d25474 for ietf-openpgp-bks; Fri, 18 Jan 2002 06:41:06 -0800 (PST)
Received: from crystal.i-net.gr (foobar@pc217.dialup.uoi.gr [195.130.119.217]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0IEf3325470 for <ietf-openpgp@imc.org>; Fri, 18 Jan 2002 06:41:03 -0800 (PST)
Received: from localhost ([127.0.0.1] helo=crystal ident=foobar) by crystal.i-net.gr with smtp (Exim 3.32 #1 (Debian)) id 16RaBA-00033E-00 for <ietf-openpgp@imc.org>; Fri, 18 Jan 2002 16:39:40 +0200
Date: Fri, 18 Jan 2002 16:18:46 +0200
From: Nikos Mavroyanopoulos <nmav@hellug.gr>
To: ietf-openpgp@imc.org
Subject: Re: Fw: [ietf-tls] using openpgp with tls
Message-Id: <20020118161846.7db5732b.nmav@hellug.gr>
In-Reply-To: <87d708ol37.fsf@alberti.gnupg.de>
References: <20020117085114.3854af79.nmav@hellug.gr> <sjmg055ni6v.fsf@kikki.mit.edu> <87u1tkoqb4.fsf@alberti.gnupg.de> <sjmlmewnb64.fsf@kikki.mit.edu> <87lmewopaz.fsf@alberti.gnupg.de> <sjmhepkna81.fsf@kikki.mit.edu> <87hepkoo0f.fsf@alberti.gnupg.de> <sjm8zawn95c.fsf@kikki.mit.edu> <87d708ol37.fsf@alberti.gnupg.de>
X-Mailer: Sylpheed version 0.6.5claws25 (GTK+ 1.2.10; i386-debian-linux-gnu)
X-URL: http://members.hellug.gr/nmav
X-PGP-KeyID: B15C37D1
X-Request-PGP: finger:nmav@members.hellug.gr
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
Content-Transfer-Encoding: 7bit

On Thu, 17 Jan 2002 20:04:28 +0100 Werner Koch <wk@gnupg.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@hellug.gr