On 25 Apr 2006, at 8:12 PM, David Shaw wrote:
Section 5.1.2, Signature Types, says:
There are a number of possible meanings for a signature, which are
specified in a signature type octet in any given signature. See
section 5.2.4, "Computing Signatures," for detailed information on
how to compute and verify signatures of each type.
There are a number of possible meanings for a signature, which may
be indicated in a signature type octet in any given signature.
Please note that the vagueness of these meanings is not a flaw,
but
a feature of the system. Because OpenPGP places final authority
for
validity upon the receiver of a signature, it may be that one
signer's casual act might be more rigorous than some other
authority's positive act.
The two opening sentences are redundant. Suggest:
There are a number of possible meanings for a signature, which are
indicated in a signature type octet in any given signature.
Please note that the vagueness of these meanings is not a flaw,
but a feature of the system. Because OpenPGP places final
authority
for validity upon the receiver of a signature, it may be that one
signer's casual act might be more rigorous than some other
authority's positive act. See section 5.2.4, "Computing
Signatures," for detailed information on how to compute and verify
signatures of each type.
(Combining the two)
Done.
*******************
Section 5.2.2, Version 3 Signature Packet Format has a sentence that
reads "The details of the calculation are different for DSA signature
than for RSA signatures." That should be "DSA signatures" (plural).
Done.
*******************
In section 5.2.3.12. Revocable, the second sentence reads "Packet body
contains a Boolean flag indicating whether the signature is
revocable." Suggest adding a "The" to read "The packet body
contains..."
Done.
*******************
In section 9.3. Compression Algorithms, suggest adding:
Algorithm 0, "uncompressed," may only be used to denote a
preference for uncompressed data in the preferred compression
algorithms subpacket (section 5.2.3.9). Implementations MUST NOT
use uncompressed in Compressed Data Packets.
(We had the same problem with using cipher algorithm 0 in encrypted
data packets, and made that MUST NOT as well)
I want to quibble over this one.
The reason we don't allow 0 in encrypted packets is because we don't
want to have "encrypted" data. It's a security reason. There's no
security reason here. While it's perhaps stupid to make a compressed
packet that has no compression (you could just have a literal
packet), there is no *security* reason to object to it.
Also, there's no particular code reason to object to it, either; you
have to handle the case, and rather than error out, why not just
proceed?
Since these are the last call edits and this change could cause code
changes -- someone who was handing compression-uncompressed would now
have to make this an error, I'm not taking the edit.
*******************
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.
Done.
*******************
Section 12.5, DSA, has a sentence that reads "It MUST NOT implement a
DSA signature with a q size of less than 160 bits." That should be a
"DSA key" rather than a "DSA signature".
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 does not want to have the 512-bit
data length.
Suggest:
* SHA224 and SHA384 require the same work as SHA256 and SHA512
respectively. In general, there are few reasons to use them
outside of DSS compatibility. You need a situation where one
needs more security than smaller hashes, but does not want to
have the full 256-bit or 512-bit data length.
Done, but I made them "SHA-" because if I don't, you'll find that nit
in IETF Last Call. :-)
David
Jon