Subject: rfc2440bis checklist

From: Werner Koch <[email-masked]>
Date: Wed, 2 Feb 2000 14:14:14 +0100

Hi, 

I have compiled the list of SHOULD and MUST.  What do we else need to
check interoperability?  

This is a list of all MUST and SHOULD requirements of the
draft-ietf-openpgp-rfc2440bis-00.txt.  Note, that the section
numbering in 5.2.3 is shifted against rfc2440.

Version: wk 2000-02-02

Section  MS  Summary of requirement
-------  --  ----------------------

2.3	 S   OpenPGP implementations SHOULD compress the message after
	     applying the signature but before encryption.

2.4	 S   Implementations SHOULD provide Radix-64 conversions.

2.4	 S   An application that implements OpenPGP for messaging
	     SHOULD implement OpenPGP-MIME (rfc2015).

3.3	 S   Implementations SHOULD NOT assume that Key IDs are unique.

3.6.2	 S   Implementations SHOULD use salted or iterated-and-salted S2K.

3.6.2.1  S   Secret Key encryption with an implicit use of MD5 and IDEA
	     SHOULD NOT be generated.

4.2.1	 S   An implementation SHOULD NOT use indeterminate length packets
	     of old format except where the end of the data will be clear
	     from the context.

4.2.2.4  M   The last length header in the packet MUST NOT be a
	     partial Body Length header.

4.2.3	 M   1st partial length MUST be at least 512 bytes long.

4.2.3	 M   Partial Body Lengths MUST NOT be used for packet types
	     other than compressed (8), encrypted (9), literal (11).

5.1	 M   For multiple Public Key Encrypted Session Key packets,
	     implementations MUST make new PKCS-1 padding for each key.

5.2	 M   Implementations MUST accept V3 signatures.

5.2	 S   Implementations SHOULD generate V4 signatures.

5.2.2	 M   The one-octet length of following hashed material
	     MUST be 5 in V3 signature packets.

5.2.2	 M   DSA signatures MUST use hashes with a size of 160 bits.

5.2.3.1  S   An implementation SHOULD ignore any signature subpacket of a type
	     that it does not recognize, but if is marked crtitical the
	     implemenation SHOULD consider the signature in error.

5.2.3.1  S   Implementations SHOULD implement "preferences".

5.2.3.3  S   An implementation SHOULD allow the user to rewrite the
	     self-signature, and important information in it.

5.2.3.4  M   The signature creation time sub-packet MUST be in the hashed
	     area of a V4 signature packet.

5.2.3.13 S   Trust signature: Implementations SHOULD emit values
	     of 60 for partial trust and 120 for complete trust.

5.2.3.15 S   Revocation key: If the "sensitive" flag is set, an implementation
	     SHOULD NOT export this signature to other users except in cases
	     where the data needs to be available.

5.2.3.16 M   In Notation Data subpacket all undefined flags in the flag
	     field MUST be zero.

5.2.3.17 M   In key server preferences, all undefined flags MUST be zero.

5.2.3.21 M   In the Key flags an implementaion MOST NOT assume a fixed size.

5.2.3.21 S   Key flags SHOULD be placed only on a direct-key signature (type
	     0x1f) or a subkey signature (type 0x18).

5.2.3.23 S   An implementation SHOULD implement the Reason For Revocation
	     subpacket, include it in all revocation signatures, and
	     interpret revocations appropriately.

5.2.3.23 S   A revocation of a self-signature on a user id SHOULD include
	     the 0x20 reason code.  [The draft calls it subpacket, but this
	     seems to be wrong]

5.2.4.1  S   An implementation SHOULD put the two mandatory subpackets,
	     creation time and issuer, as the first subpackets in the list.

5.2.4.1  S   An implementation SHOULD use the last subpacket in the signature
	     to resove conflicts.

5.3	 M   The S2K specifier in a Symmentric Key Encrypted Session Key
	     packet MUST be Salted or Iterated and Salted.

5.5.2	 M   v2 packets MUST NOT be generated.

5.5.2	 S   OpenPGP implementations SHOULD create keys with version 4 format.

5.5.2	 M   An implementation MUST NOT create a v3 packet with an algorithm
	     other than RSA.

5.5.2	 S   V3 keys SHOULD only be used for backward compatibility.

5.5.3	 S   Implementations SHOULD use a string-to-key specifier except for
	     backward compatibility.

5.8	 M   Marker packets (tag 10) MUST be ignored when received.

5.10	 S   Trust packets SHOULD NOT be emitted to output streams that are
	     transferred to other users.

5.10	 S   Trust pakets SHOULD be ignored on any input other than local
	     keyring files.

6.2	 M   The armor header lines MUST start at the beginning of a line.

6.2	 M   The armor header lines MUST NOT have text following them on the
	     same line.

6.2	 S   The MessageID SHOULD NOT appear unless it is in a multi-part
	     message.

6.2	 M   The Message Armor header 'MessageID' (if it appears) MUST be
	     computed from the encrypted signed message in a deterministic
	     fashion.

9.1	 M   MUST implement DSA for signatures.

9.1	 M   MUST implement ElGamal for encryption.

9.1	 S   Implementations SHOULD implement RSA keys.

9.2	 M   MUST implement 3-DES for symmetric encryption.

9.2	 S   Implementations SHOULD implement IDEA.

9.2	 S   Implementations SHOULD implement CAST5.

9.3	 M   Implementations MUST implement uncompressed data.

9.3	 S   Implementations SHOULD implement ZIP.

9.4	 M   Implementations MUST implement SHA-1.

9.4	 S   Implementations SHOULD implement MD5.

11.1	 M   In keys with main keys and sub keys, the primary key MUST be
	     capable of signing.
	     Remark:  This make it possible to have a single encryption only
		      key

12.1	 MS  If an algorithm used in encryption is not in the user's
	     preference list, the implementation SHOULD decrypt anyway
	     but MUST warn the user of the protocol violation.

12.1	 M   An implementation MUST NOT use a symmetric algorithm that is not
	     in the recipient's preference list.

12.1	 S   An implementation MAY, but SHOULD NOT use IDEA to solve
	     an algorithm conflict with a V3 key.

12.2.1	 M   An implementation MUST NOT use a compression algorithm that is
	     not in the compression preference vector.

12.2.1	 M   An implementation MUST implement the compression preference to
	     the degree of recognizing when to send an uncompressed message.

12.3	 M   Implementations MUST NOT use plaintext in Symmetrically
	     Encrypted Data Packets; they must use Literal Data Packets.

12.4	 M   Implementations supporting RSA in V4 keys MUST implement all
	     MUST features from V4 key section.

12.4	 S   An implementation SHOULD NOT create keys of types
	     RSA-signature-only and RSA-encrypt-only.

12.4	 S   An implementation SHOULD NOT implement RSA keys of size
	     less than 768 bits.

12.5	 M   If an implementation allows ELGamal signatures, then it
	     MUST use the algorithm id 20 for an ElGamal public key that
	     can sign.

12.5	 S   Implementations SHOULD choose an ElGamal prime p, so that
	     (p-1)/2 are also primes.

12.5	 S   An implementation SHOULD NOT implement Elgamal keys of
	     size less than 768 bits.

12.6	 S   An implementation SHOULD NOT implement DSA keys of
	     size less than 768 bits.

12.6	 M   DSA keys MUST be an even multiple of 64 bits long.

[based on initial work by Tony Mione <[email-masked]>
 posted to the OpenPGP list Tue, 20 Jul 1999 17:09:08 -0400]

-- 
Werner Koch at guug.de           www.gnupg.org           keyid 621CC013