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