bis-16 comments

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)

*******************

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

*******************

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

*******************

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)

*******************

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.

*******************

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

*******************

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.

David

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

On Mon, May 08, 2006 at 02:52:30PM -0700, Jon Callas wrote:

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

You're right.  It's better left out.

David