-----BEGIN PGP SIGNED MESSAGE-----
I agreed to take on a couple of work items at the OpenPGP meeting in Oslo,
Norway. One of those work items was to enumerate the MUSTS in RFC2440 in
order to help vendors begin conformance testing.
Following is the list I came up with (anyone with some spare time, please
check me on the list). I also plan on forwarding SHOULDS, MAYS, SHOULD
NOTS, etc. hopefully within the next week.
The discussion we had openned the possibility of grouping the lists
together and adding a small amount of additional information. The result
would be an informational RFC probably titled 'OpenPGP Implementor's
Guide.' I am willing to do the bulk of the wordsmithing on the document and
know of two other possible co-authors. Is there any interest in such a
document?
Anyway, Here are the MUSTS that I found. I have included section numbers
from 2440 and a brief paraphrased description. For more information, read
2440.
=====
OpenPGP MUSTS
Section Summary of requirement
- ------- ----------------------
4.2.3 1st partial length MUST be at least 512 bytes long.
5.1 For multiple Public Key Encrypted Session Key packets,
implementations MUST make new PKCS-1 padding for each key.
5.2 Implmenetations MUST accept V3 signatures.
5.2.2 1st octet length of hash material MUST be 5. in V3 signature packet.
5.2.2 DSA signatures MUST use hashes with a size of 160 bits to match
q. The size of the groups generated by the DSA key's generator value.
5.2.3.3 The signature creation time sub-packet MUST be in the hashed
area of a V4 signature packet.
5.2.3.15 In Notation Data subpacket all undefined flags in the flag
field MUST be zero.
5.2.3.16 In key server preferences, all undefined flags MUST be zero.
5.3 The S2K specifier in a Symmentric Key Encrypted Session Key
packet MUST be Salted or Iterated and Salted. since the IV
is 0. This is to prevent identical decryption keys if a
passphrase is re-used.
5.8 Marker packets (tag 10) MUST be ignored when received.
6.2 The Message Armor header 'MessageID' (if it appears) MUST be
computed from the encrypted signed message in a deterministic
fashion (rather than being random) to prevent covert
channels.
9.1 MUST implement DSA for signatures.
9.2 MUST implement 3-DES for symmetric encryption.
9.3 MUST implement uncompressed data.
9.4 MUST implement SHA-1.
11.1 In keys with main keys and sub keys, the primary key MUST be
capable of signing.
12.1 If an algorithm is 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.4 Implementations supporting RSA in V4 keys MUST implement all
MUST features from V4 key section.
12.5 If an implementation allows ELGammal signatures, then it
MUST use the algorithm id 20 for an ElGammal public key that
can sign.
=====
Tony Mione, RUCS/TD, Rutgers University, Hill 055, Piscataway,NJ - 732-445-0650
mione(_at_)noc(_dot_)rutgers(_dot_)edu W3:
http://noc.rutgers.edu/~mione/
PGPFP:D4EEA987E870277C 24AAE6E9E6ABD088 ***** Important: Rom 10:9-11 *****
Author of 'CDE and Motif : A Practical Primer', Prentice-Hall PTR
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Processed by mkpgp2.1, a Pine/PGP interface.
iQCVAwUBN5TlVAfNcGHdn+zRAQH8ZQQAnogLjUI/4ICOBXT8aLWbdkvjN9u6EKYp
tFfu3CcCD22MGT8mPXM2XVdttfOAxhOhz967Zv1uubxljuMdM0/N1zOdV/FxvW0X
cDM6Dz1QGaptGCZ9aCyIDN2jL3RAofT7hSiIITtuqHUk79p8G9BYbNVfZ4EFj+49
cmBuBQ199Mc=
=0oOz
-----END PGP SIGNATURE-----