IETF Logo Mail Archive

Re: DEADBEEF vs SHA1

Lutz Donnerhacke <lutz@iks-jena.de> Mon, 21 February 2011 12:35 UTC

Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p1LCZAVF052226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Feb 2011 05:35:10 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id p1LCZArr052225; Mon, 21 Feb 2011 05:35:10 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org)
X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from branwen.iks-jena.de (branwen.iks-jena.de [217.17.192.90]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p1LCZ87I052220 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf-openpgp@imc.org>; Mon, 21 Feb 2011 05:35:10 -0700 (MST) (envelope-from news@branwen.iks-jena.de)
X-SMTP-Sender: 127.0.0.1
Received: from branwen.iks-jena.de (localhost [127.0.0.1]) by branwen.iks-jena.de (8.14.3/8.14.1) with ESMTP id p1LCZ5sx011166 for <ietf-openpgp@imc.org>; Mon, 21 Feb 2011 13:35:07 +0100
X-MSA-Host: branwen.iks-jena.de
Received: (from news@localhost) by branwen.iks-jena.de (8.14.3/8.14.1/Submit) id p1LCZ4Dg011165 for ietf-openpgp@imc.org; Mon, 21 Feb 2011 13:35:04 +0100
To: ietf-openpgp@imc.org
Path: not-for-mail
From: Lutz Donnerhacke <lutz@iks-jena.de>
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: DEADBEEF vs SHA1
Date: Mon, 21 Feb 2011 12:35:04 +0000
Organization: IKS Jena, Thüringen Netz, Fitug
Lines: 8
Message-ID: <slrnim4mvo.v2.lutz@belenus.iks-jena.de>
References: <C997753D-9BB7-445C-A95C-260B3BE11F78@callas.org>
NNTP-Posting-Host: belenus.iks-jena.de
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Trace: branwen.iks-jena.de 1298291704 10788 217.17.192.34 (21 Feb 2011 12:35:04 GMT)
X-Complaints-To: usenet@iks-jena.de
NNTP-Posting-Date: Mon, 21 Feb 2011 12:35:04 +0000 (UTC)
User-Agent: slrn/pre0.9.9-77 (Linux)
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>

* Jon Callas wrote:
> The bottom line is that a key id in that context is a 64-bit binary key
> into a database. That's all that it is.

And it is *not unique*. Software has to deal with multiple keys having the
same ID. Not importing v3, because it might generate such ambigious cases,
is not an acceptable solution. V3 keys only enforce standard compliant
behaviour.

v2.23.0 | Report a Bug | By Email