Re: DEADBEEF vs SHA1

Jon Callas <jon@callas.org> Fri, 18 February 2011 18:29 UTC

Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p1IITS90086386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Feb 2011 11:29:28 -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 p1IITS1D086382; Fri, 18 Feb 2011 11:29:28 -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 merrymeet.com (thing2.merrymeet.com [173.164.244.100] (may be forged)) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p1IITSWU086373 for <ietf-openpgp@imc.org>; Fri, 18 Feb 2011 11:29:28 -0700 (MST) (envelope-from jon@callas.org)
Received: from localhost (localhost [127.0.0.1]) by merrymeet.com (Postfix) with ESMTP id 7CA9A2E060 for <ietf-openpgp@imc.org>; Fri, 18 Feb 2011 10:30:53 -0800 (PST)
Received: from merrymeet.com ([127.0.0.1]) by localhost (host.domain.tld [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 41082-05 for <ietf-openpgp@imc.org>; Fri, 18 Feb 2011 10:30:51 -0800 (PST)
Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTPA id 342712E05F for <ietf-openpgp@imc.org>; Fri, 18 Feb 2011 10:30:51 -0800 (PST)
Received: from [10.0.23.19] ([173.164.244.98]) by keys.merrymeet.com (PGP Universal service); Fri, 18 Feb 2011 10:29:25 -0800
X-PGP-Universal: processed; by keys.merrymeet.com on Fri, 18 Feb 2011 10:29:25 -0800
Mime-Version: 1.0 (Apple Message framework v1082)
Subject: Re: DEADBEEF vs SHA1
From: Jon Callas <jon@callas.org>
In-Reply-To: <315DE4B7-F5C7-4FA6-9A0F-2CAD305D4DF2@jabberwocky.com>
Date: Fri, 18 Feb 2011 10:29:24 -0800
Message-Id: <C997753D-9BB7-445C-A95C-260B3BE11F78@callas.org>
References: <D8E81788-AF18-448F-BA39-56185C1F0672@jabberwocky.com> <4D5DB5A9.9040509@iang.org> <315DE4B7-F5C7-4FA6-9A0F-2CAD305D4DF2@jabberwocky.com>
To: IETF OpenPGP Working Group <ietf-openpgp@imc.org>
X-Mailer: Apple Mail (2.1082)
X-PGP-Encoding-Format: Partitioned
X-PGP-Encoding-Version: 2.0.2
X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: quoted-printable
X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=us-ascii
Content-Type: text/plain; charset="us-ascii"
X-Virus-Scanned: Maia Mailguard
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by hoffman.proper.com id p1IITSWU086377
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>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I think it's very important to understand the distinction between the protocol(s) we have and machines that implement the protocols. Those machines can be APIs (e.g. OpenPGP SDK, Bouncy Castly, etc.) applications (e.g. GnuPG, PGP Desktop), appliances (e.g. PGP Universal), but they are not the same thing. It's perfectly fine for an application to do some right thing that is not supported by some protocol.

For example, when I was at PGP Corporation, I used to say a lot that OpenPGP is a standard (and a protocol), but PGP is software. The PGP Software implements the OpenPGP protocol, but it also implements the S/MIME protocol, as well as SSL/TLS, X.509, SMTP, and so on. 

It's with that in mind, the difference between the protocol and software is an important part of this discussion.

I agree with Ian completely that there are people who have old (v3 key) encrypted and signed data that they need to get to. Decrypting data is the most important thing. I'm sure that I have some things in old backups that maybe I'd like to decrypt some day without having to break the key they're encrypted to.

There are a number of ways to deal with this. For example, I could have a copy of PGP 2.6.3 lying around and use that to decrypt my old things. That's only a mild inconvenience. Similarly, PGP or GnuPG could keep v3 keys around *as* *software* for such archival purposes. It might even make sense from a user experience aspect to have them in historic keyrings that are not in one's face every day. Or GnuPG could handle it despite it not being any longer standard, or ....

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. Yeah, it's derived with a function, but it's just a key.

IETF RFCs are not programming manuals. They are also not requirements documents for applications. They are descriptions of how to properly interoperate, and that's all. Application designers still have to think.

	Jon


-----BEGIN PGP SIGNATURE-----
Version: PGP Universal 2.10.0 (Build 554)
Charset: us-ascii

wj8DBQFNXrqFsTedWZOD3gYRAj16AKCZ5TrOlbYAj6Zb0xyLCNkbA2NKPQCgriab
hjgYuRyiS625/fIrFoaUqB4=
=BuD3
-----END PGP SIGNATURE-----