On 5 Dec 2005, at 11:32 AM, David Shaw wrote:
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..."
done.
*****
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.
done.
*****
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").
done.
*****
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.
done.
*****
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".
done.
*****
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.
done.
*****
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".
done.
*****
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".
done. (And apropos of other discussions, this is the fix for the
Klima-Rosa attack, among others.)
*****
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.
done.
*****
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).
Changed to:
Note that this example has extra indenting; an actual armored message
would have no leading whitespace.
*****
9.4. Hash Algorithms mentions MD5. Suggest adding a reminder to this
section that MD5 is deprecated.
done.
*****
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.
done.
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.
done. Both musts.
*****
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.
Not only did I fix this, but I removed all the places where a period
was followed by two spaces so that we don't get more of them.
*****
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."
done, but made it MUST.
*****
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.
done.
*****
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".
done
*****
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.
removed
*****
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/>.
done.
*****
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.
I'm leaving them in. Changed to "Informative".
Jon