ietf-openpgp
[Top] [All Lists]

rfc2440bis checklist

2000-02-02 06:20:22
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 <mione(_at_)noc(_dot_)rutgers(_dot_)edu>
 posted to the OpenPGP list Tue, 20 Jul 1999 17:09:08 -0400]


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


<Prev in Thread] Current Thread [Next in Thread>
  • rfc2440bis checklist, Werner Koch <=