Some -15 text nits

[David Shaw <[e-mail]>]

These are just some fiddly language nits for -15.  Nothing terribly
controversial I hope.

******

The "IANA Considerations" section in the beginning of the draft
contains this:

 Instead requests to define new tag values (say for new encryption
 algorithms for example) should be forwarded to the IESG Security Area
 Directors for consideration or forwarding to the appropriate IETF
 Working Group for consideration.

"forwarded... or forwarding" doesn't parse very well.  I suggest:

 Instead, requests to define new tag values (say for new encryption
 algorithms) should be forwarded to the IESG Security Area Directors
 or the appropriate IETF Working Group for consideration.

******

Section 3.7.1. String-to-key (S2K) specifier types, refers to S2K
value 2 as "illegal".  Everywhere else in the document, such
do-not-use values are referred to as "reserved".

******

Section 3.7.2.1. Secret key encryption says "For compatibility, when
an S2K specifier is used, the special value 255 is stored in the
position where the hash algorithm octet would have been in the old
data structure.".  I suggest changing that to read "... the special
value 255 or 254 ..." since 254 is a legal value there, as the table
immediately after that paragraph makes clear.

******

Section 3.7.2.1. Secret key encryption, and section 5.3. Symmetric-Key
Encrypted Session Key Packets refer to "passphrase" as "pass phrase".
This is inconsistent with the rest of the document which always uses
"passphrase".

******

Section 4.2.2.4. Partial Body Lengths has a paragraph that begins "It
might also be encoded..."  That doesn't make sense since there is no
"it" that the sentence refers to.  I believe that paragaph belongs in
the following section (4.2.3. Packet Length Examples), as the "it" in
question refers to the example "packet with length 100000" from 4.2.3.

******

In section 5.2.1. Signature Types, the signature class 0x18
description says "This signature is calculated directly on the subkey
itself, not on any User ID or other packets", but in fact 0x18
signatures are calculated on the primary key plus subkey.  Similarly,
the 0x19 description says "This signature is calculated directly on
the primary key itself, and not on any User ID or other packets", but
in reality it is calculated exactly the same way as 0x18 is
(primary+subkey).

To be sure, 5.2.4 gets this right, and 5.2.1 defers to 5.2.4, but it
would still be nice to not give two different answers for this.

******

5.2.2. Version 3 Signature Packet Format says "The hash h is PKCS-1
padded exactly the same way as for the above described RSA
signatures".  This doesn't really make sense as there is no
description of RSA signatures above.

David