Re: bis-16 comments

[Jon Callas <[e-mail]>]

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