Re: Some -15 text nits

[Jon Callas <[e-mail]>]

On 30 Nov 2005, at 8:13 AM, David Shaw wrote:

>
> 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.
>

This was text given to me by the IESG. In general, I don't mess with  
such things until they tell me to mess with them.

> ******
>
> 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".
>

changed

> ******
>
> 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.
>

done

> ******
>
> 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".
>

removed all uses of "pass phrase" (two words), making them one word.

> ******
>
> 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.
>

I think you're right. Moved.

> ******
>
> 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.
>

fixed. Here's what they say now:

    0x18: Subkey Binding Signature
        This signature is a statement by the top-level signing key that
        indicates that it owns the subkey. This signature is calculated
        directly on the primary key and subkey, not on any User ID or
        other packets. A signature that binds a signing subkey MUST have
        an embedded signature subpacket in this binding signature which
        contains a 0x19 signature made by the signing subkey on the
        primary key.

    0x19 Primary Key Binding Signature
        This signature is a statement by a signing subkey, indicating
        that it is owned by the primary key and subkey. This signature
        is calculated directly on the primary key itself, and not on any
        User ID or other packets.



> ******
>
> 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.
>

All right, it appears to be unnecessary. Removed.

	Jon