Some -15 text nits, part 2
David Shaw <dshaw@jabberwocky.com> Mon, 05 December 2005 19:50 UTC
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjMMQ-0006D3-BA for openpgp-archive@megatron.ietf.org; Mon, 05 Dec 2005 14:50:55 -0500
Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02846 for <openpgp-archive@lists.ietf.org>; Mon, 5 Dec 2005 14:50:02 -0500 (EST)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB5JWRJY091897; Mon, 5 Dec 2005 11:32:27 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id jB5JWRdi091896; Mon, 5 Dec 2005 11:32:27 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from foobar.cs.jhu.edu (foobar.cs.jhu.edu [128.220.13.173]) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB5JWQaE091887 for <ietf-openpgp@imc.org>; Mon, 5 Dec 2005 11:32:27 -0800 (PST) (envelope-from dshaw@jabberwocky.com)
Received: from walrus.hsd1.ma.comcast.net (walrus.hsd1.ma.comcast.net [24.60.132.70]) by foobar.cs.jhu.edu (8.11.6/8.11.6) with ESMTP id jB5JWOS18352 for <ietf-openpgp@imc.org>; Mon, 5 Dec 2005 14:32:24 -0500
Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id jB5JWLX6023652 for <ietf-openpgp@imc.org>; Mon, 5 Dec 2005 14:32:21 -0500
Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id jB5JWIvO024780 for <ietf-openpgp@imc.org>; Mon, 5 Dec 2005 14:32:18 -0500
Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id jB5JWIWm024779 for ietf-openpgp@imc.org; Mon, 5 Dec 2005 14:32:18 -0500
Date: Mon, 05 Dec 2005 14:32:18 -0500
From: David Shaw <dshaw@jabberwocky.com>
To: ietf-openpgp@imc.org
Subject: Some -15 text nits, part 2
Message-ID: <20051205193218.GA24459@jabberwocky.com>
Mail-Followup-To: ietf-openpgp@imc.org
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
User-Agent: Mutt/1.5.11
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>
Here is the second half of a -15 proofreading. As before, these are just language nits, and should not have any functional significance. I did note a few items that might be considered functional, but I'm sending them in a different mail so as to not mix them up. Many apologies for the late submission of these. ***** 5.1. Public-Key Encrypted Session Key Packets says "Note that when an implementation forms several PKESKs with one session key, forming a message that can be decrypted by several keys, the implementation MUST make new PKCS-1 encoding for each key." This needs an "a", so as to read "...MUST make a new PKCS-1 encoding..." ***** 5.2.3.3. Notes on Self-Signatures says "If the key is located by key ID, the algorithm of the primary User ID of the key provides the default symmetric algorithm." Suggest changing "default" to "preferred", as preferred is the word used in all the other examples there. ***** 5.2.3.7. Preferred symmetric algorithms says "Algorithm numbers in section 9." This should be "Algorithm numbers are in section 9." (i.e. add an "are"). ***** 5.2.3.15. Revocation key mentions "1 octet of algid" in the definition. Suggest "1 octet of PK algorithm ID" or similar as we never define "algid" in the document. ***** 5.2.3.23. Reason for Revocation has a sentence "Such a revocation SHOULD include an 0x20 subpacket." Suggest changing this to "Such a revocation SHOULD include an 0x20 code." or similar. 0x20 in this case is not a subpacket, and the rest of this section refers to it as a "code". ***** 5.3. Symmetric-Key Encrypted Session Key Packets has two small formatting bugs. The lines beginning "Zero or more Encrypted Session Key packets" and "The decryption result consists" are both indented an extra space. ***** 5.5.2. Public Key Packet Formats says: V2 keys are identical to the deprecated V3 keys except for the version number. An implementation MUST NOT generate them and may accept or reject them as it sees fit. Suggest capitalizing the "may". ***** 5.5.3. Secret Key Packet Formats has the sentence "The reason for this is that there are some attacks on the private key that can undetectably modify the secret key". That doesn't really parse well. Suggest "The reason for this is that there are some attacks that involve undetectably modifying the secret key". ***** 5.6. Compressed Data Packet (Tag 8) has a note about ZIP and ZLIB, but not BZip2. It might be good to add: BZip2-compressed packets are compressed using the BZip2 algorithm. ***** 6.6. Example of an ASCII Armored Message says "Note that this example is indented by two spaces." The example is, in fact, indented by three spaces, but even so should probably be indented by four spaces like the rest of the document. (Hey, I did say these were nits). ***** 9.4. Hash Algorithms mentions MD5. Suggest adding a reminder to this section that MD5 is deprecated. ***** 10.1. Transferable Public Keys has a paragraph beginning "After the User ID or Attribute packets there may be one or more Subkey packets." This should be "zero or more" Subkey packets, as is correctly stated a few paragraphs up from there. In the same section, there is a paragraph beginning "Each Subkey packet must be followed by one Signature packet", there is a sentence "For subkeys that can issue signatures, the subkey binding signature must contain an embedded signature subpacket with a primary key binding signature (0x19) issued by the subkey on the top level key". Suggest capitalizing the MUST. ***** In section 10.2. OpenPGP Messages, the paragraph beginning "In addition, decrypting a Symmetrically Encrypted Data Packet" has a blank line in the middle of the paragraph. ***** Section 11.1. Key Structures says "A subkey always has a single signature after it that is issued using the primary key to tie the two keys together. This binding signature may be in either V3 or V4 format, but SHOULD be V4." Suggest adding "Subkeys that can issue signatures must have a V4 binding signature due to the REQUIRED embedded primary key binding signature." ***** 12.1. Symmetric Algorithm Preferences says "Since it is found on a self-signature, it is possible that a keyholder may have different preferences." Suggest adding the word "multiple" as in "... multiple different preferences." In the same section, in the last paragraph, suggest removing the parentheses around the Alice example. ***** Section 13. Security Considerations says: * SHA384 requires the same work as SHA512. In general, there are few reasons to use it -- you need a situation where one needs more security than SHA256, but do not want to have the 512-bit data length. "but do not want" should probably be "but does not want". ***** 14. Implementation Nits says: * PGP 2.6.X and 5.0 do not trim trailing whitespace from a "canonical text" signature. They only remove it from cleartext signatures. These signatures are not OpenPGP compliant -- OpenPGP requires trimming the whitespace. If you wish to interoperate with PGP 2.6.X or PGP 5, you may wish to accept these non-compliant signatures. This item is no longer needed as the draft no longer requires trimming whitespace from canonical text signatures. ***** In section 16. References (Normative), the reference to BZ2 points to <http://sources.redhat.com/bzip2>. This is no longer correct, and should be <http://www.bzip.org/>. ***** In section 17. References (Non-Normative), some of the references are no longer referred to (BLEICHENBACHER, DONNERHACKE, RFC1983). I'm not sure if this is a problem or not, as they are not normative anyway. Either way, I do suggest changing "Non-Normative" to "Informative" as that is the current recommended wording on rfc-editor.org. David
- Some -15 text nits, part 2 David Shaw
- Re: Some -15 text nits, part 2 Jon Callas