Fwd: Mistake in section 5.3, also in RFC2440
Jon Callas <jon@callas.org> Mon, 08 May 2006 22:30 UTC
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdEFl-0006nG-GG for openpgp-archive@lists.ietf.org; Mon, 08 May 2006 18:30:57 -0400
Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdEFl-0005TU-45 for openpgp-archive@lists.ietf.org; Mon, 08 May 2006 18:30:57 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k48M4QrK066729; Mon, 8 May 2006 15:04:26 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k48M4QEA066728; Mon, 8 May 2006 15:04:26 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k48M4PUm066714 for <ietf-openpgp@imc.org>; Mon, 8 May 2006 15:04:25 -0700 (MST) (envelope-from jon@callas.org)
Received: from keys.merrymeet.com (63.73.97.166) by merrymeet.com with ESMTP (Eudora Internet Mail Server X 3.2.7) for <ietf-openpgp@imc.org>; Mon, 8 May 2006 15:04:24 -0700
Received: from [63.251.255.205] ([63.251.255.205]) by keys.merrymeet.com (PGP Universal service); Mon, 08 May 2006 15:04:24 -0700
X-PGP-Universal: processed; by keys.merrymeet.com on Mon, 08 May 2006 15:04:24 -0700
Mime-Version: 1.0 (Apple Message framework v749.3)
References: <192E2551-1E74-478E-969F-D84AE29E2D24@callas.org>
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <7C98DD8C-6F6C-461E-8A13-5B848CE04060@callas.org>
Content-Transfer-Encoding: 7bit
From: Jon Callas <jon@callas.org>
Subject: Fwd: Mistake in section 5.3, also in RFC2440
Date: Mon, 08 May 2006 15:04:20 -0700
To: OpenPGP <ietf-openpgp@imc.org>
X-Mailer: Apple Mail (2.749.3)
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>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4
I forgot to reply-all Jon Begin forwarded message: > From: Jon Callas <jon@callas.org> > Date: 8 May 2006 2:40:03 PM PDT > To: Hal Finney <hal@finney.org> > Subject: Re: Mistake in section 5.3, also in RFC2440 > > > On 25 Apr 2006, at 7:28 PM, Hal Finney wrote: > >> >> I noticed that the language in section 5.3 on Symmetric-Key Encrypted >> Session Key packets is not right: >> >> 5.3. Symmetric-Key Encrypted Session Key Packets (Tag 3) >> >> The Symmetric-Key Encrypted Session Key packet holds the >> symmetric-key encryption of a session key used to encrypt a >> message. >> Zero or more Encrypted Session Key packets and/or Symmetric-Key >> Encrypted Session Key packets may precede a Symmetrically >> Encrypted >> Data Packet that holds an encrypted message. >> >> The second sentence should begin "Zero or more Public-Key Encrypted >> Session Key packets and/or Symmetric-Key Encrypted Session Key >> Packets..." >> It left off "Public-Key" and just refers to "Encrypted Session Key >> packets" which is not a packet type. In particular, referring to >> "Encrypted Session Key packets and/or Symmetric-Key Encrypted Session >> Key Packets" is incoherent. >> >> The langage in 5.1, for comparsion: >> >> 5.1. Public-Key Encrypted Session Key Packets (Tag 1) >> >> A Public-Key Encrypted Session Key packet holds the session >> key used >> to encrypt a message. Zero or more Encrypted Session Key packets >> (either Public-Key or Symmetric-Key) may precede a Symmetrically >> Encrypted Data Packet, which holds an encrypted message. >> >> This is not ideal in terms of the packet names; you have to mentally >> move the prefixes listed in the parenthesis up and put them in >> front of >> Encrypted Session Key. But given that slight lapse in clarity, it is >> basically correct, and is not as bad as 5.3. >> >> All this language is unchanged since RFC2440. >> >> I do think we should fix at least 5.3, because the present wording is >> meaningless and confusing. If we do that I'd suggest changing the >> 2nd >> sentence of 5.1 to match that of 5.3. >> >> Hal Finney >> > > Done. > > Jon
- Mistake in section 5.3, also in RFC2440 "Hal Finney"
- Fwd: Mistake in section 5.3, also in RFC2440 Jon Callas