Re: Some -15 text nits, part 2

[Jon Callas <[e-mail]>]

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