Re: bis-16 comments

Jon Callas <jon@callas.org> Mon, 08 May 2006 22:16 UTC

Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdE1W-0000ot-6e for openpgp-archive@lists.ietf.org; Mon, 08 May 2006 18:16:14 -0400
Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdE1U-0004we-ON for openpgp-archive@lists.ietf.org; Mon, 08 May 2006 18:16:14 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k48LqcT9066126; Mon, 8 May 2006 14:52:38 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k48Lqcbv066125; Mon, 8 May 2006 14:52:38 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k48Lqbuf066119 for <ietf-openpgp@imc.org>; Mon, 8 May 2006 14:52:37 -0700 (MST) (envelope-from jon@callas.org)
Received: from keys.merrymeet.com (63.73.97.166) by merrymeet.com with ESMTP (Eudora Internet Mail Server X 3.2.7); Mon, 8 May 2006 14:52:35 -0700
Received: from [63.251.255.205] ([63.251.255.205]) by keys.merrymeet.com (PGP Universal service); Mon, 08 May 2006 14:52:35 -0700
X-PGP-Universal: processed; by keys.merrymeet.com on Mon, 08 May 2006 14:52:35 -0700
In-Reply-To: <20060426031250.GA11005@jabberwocky.com>
References: <20060426031250.GA11005@jabberwocky.com>
Mime-Version: 1.0 (Apple Message framework v749.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <5E8B7F7D-6CE1-4F5F-98DE-31E61B13D2D4@callas.org>
Cc: ietf-openpgp@imc.org
Content-Transfer-Encoding: 7bit
From: Jon Callas <jon@callas.org>
Subject: Re: bis-16 comments
Date: Mon, 8 May 2006 14:52:30 -0700
To: David Shaw <dshaw@jabberwocky.com>
X-Mailer: Apple Mail (2.749.3)
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c


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