To: ietf-openpgp@imc.org
Subject: rfc2440bis-02 comments

Many of these comments come from notes I took on rfc2440, so I may
have some section numbers wrong.  I did compare these notes to the
I-D, and I believe all of them are still relevant.

1. Section 5.2 is vague about how to compute signature types 0x30 and
   0x40.  The document should specify how over what data to compute
   the hash to be signed.  There was also a comment in the list
   archives about the description of signature type 0x18, which says

	This signature is calculated directly on the subkey itself,
	not on any User ID or other packets.

   This is tremendously misleading, since the signature is actually
   computed on a hash over a prefix, the key packet, the subkey
   packet, and a trailer.  Section 5.2.4 gives a more detailed
   description of how to compute a subkey binding signature.

2. Section 5.2.4 contains another error.  It states

	Key revocation signatures (types 0x20 and 0x28) hash only the
	key being revoked.

   However, analysis of existing implementations indicates that this
   is incorrect for subkey revocation signatures (type 0x28); like
   type 0x18, both the primary key and the subkey are included in the
   hash.

3. Subpacket 23 (key server preferences) is specified to be "found
   only on a self-signature".  It should say if that means a
   direct-key self-signature (which makes the most sense to me), or
   something else.

4. The document is vague on what constitures "advisory information" in
   a signature subpacket (section 5.2.3).  I believe that unhashed
   signature subpackets were a mistake (I can expound on this if
   people want).  If existing implementations did not include unsigned
   subpackets, I would suggest removing them from the spec entirely.
   However, current implementations usually include the issuer key id
   subpacket (type 16) in the unhashed subpackets.

   Therefore, I suggest that implementations MUST not generate any
   unhashed subpackets, but SHOULD accept type 16 unsigned subpackets
   in order to process existing signatures.

5. There should be a note that the critical bit MUST be ignored on
   unhashed signature subpackets.  Otherwise, an attacker can easily
   cause any signature to stop working.

6. The terms used in 11.1 are inconsistent with the rest of the
   document, and in some places, the rest of the document is also
   inconsistent.  Where 11.1 uses "revocation self signature", the
   rest of the document uses "key revocation signature".  Where 11.1
   uses "direct key self signature", the rest of the document uses
   "direct key signature", "direct-key signature", and "Signature
   directly on a key".  Where 11.1 uses
   "binding-signature-revocation", the rest of the document uses
   "subkey revocation signature".  Where 11.1 uses
   primary-key-binding-signature", the rest of the document uses
   "subkey binding signature".