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 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 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, SHOULD accept type 16 unsigned subpackets in
order to process existing signatures, and MUST NOT accept any other
subpacket types in the unhashed subpackets.
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 fail to verify.
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".
Marc