Subject: OpenPGP conformance : MUSTS found in RFC2440

From: Tony Mione <[email-masked]>
Date: Tue, 20 Jul 1999 17:09:08 -0400 (EDT)

-----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
[email-masked]                        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

---

From: [email-masked] (Ulf Möller)
Date: Wed, 21 Jul 99 14:14 +0200

>order to help vendors begin conformance testing.

Just grepping for "MUST" won't get you anywhere. You missed important
specifications like "An OpenPGP message is a packet or sequence of
packets that corresponds to the following grammatical rules" (10.2)
and the key format requirements. On the other hand, some MUSTs just
describe facts where there are no possible choices on the
implementor's side and one might as well write "the octet is 5", "the
packet is ignored", "the flag is zero".

But there are more problems to it. If you really want to take this
task upon you, you'll have to do what the authors already should have
done before publishing a standards track RFC: look at each feature the
RFC describes and determine whether or not it is required for a
minimal implementation.

There are contradictions in the RFC:

"Hashed subpacket data. (zero or more subpackets)"
                         ^^^^
"Signature creation time [...] MUST be present in the hashed area."

The issuer key ID subpacket is never specified as a required, but
later on in the section "Subpacket Hints" the RFC mentions in passing:
"An implementation SHOULD put the two mandatory subpackets, creation
time and issuer, as the first subpackets".

The RFC doesn't say anything about accepting V4 signatures.

Much of the complexity of OpenPGP comes from the desire to be
interoperable with PGP 2. But the RFC does not even mention that PGP 2
expects certain packet length types for certain packet types.

Similarly, PGP 5 requires certain packet versions for certain
signature types. This sort of thing ought to be described in an
implementor's guide.

By the way, you forgot "MUST implement Elgamal" in your list.

---

From: Michael Elkins <[email-masked]>
Date: Wed, 21 Jul 1999 12:34:43 -0700

> There are contradictions in the RFC:

Compression also has some problems.

Section 2.1 ("Confidentiality via Encryption") states that OpenPGP encrypted
messages are usually compressed.

Section 2.3 ("Compression") states that implementations MAY compress a message
after applying a signature.

Section 9.3 ("Compression Algorithms") states that an implementation MUST
support the type 0 (uncompressed data) algorithm and SHOULD support ZIP.

It seems like this wording could lead to sever interoperability problems.

me

---

From: Jon Callas <[email-masked]>
Date: Wed, 21 Jul 1999 14:03:46 -0700

At 12:34 PM -0700 7/21/1999, Michael Elkins said:

Actually, though, that wording is there intentionally and carefully.

PGP has, since Day 1, compressed. It's also supported not 
compressing, but it was something you had to manually turn on.

It is desirable if the minimal PGP implementation could be built 
without putting in compression. Think pager.

Consequently, that's the reason for the wording you'll find there.

It's true (2.1) that PGP usually compresses. Always has, and arguably 
should in the vast majority of circumstances. (Although one could 
also argue that in some circumstances, like small messages, it's 
better not to compress. On the other other hand, you could also argue 
that compressing, even when the compressed data is bigger than 
uncompressed, has better security characteristics. But I'll bet you 
could also argue on the other other other hand that this is hooey.) 
This is really an issue for the developers, though.

I think that the wording in 2.3 (MAY) is correct. We don't want to 
say SHOULD, I don't think. It is usual, common practice, to compress 
messages. I personally encourage implementers to compress, but at 
something with a little less volume than SHOULD. Certainly, it is 
good practice to compress, and your user community will scream bloody 
murder if you don't. But is SHOULD the right word? It's always seemed 
a little too strong to me, because I want to allow my mythical 
encrypted pager network to not implement compression.

The SHOULD in 9.3 is perhaps a bit problematic. If you implement 
compression, ZIP is the algorithm to implement. Perhaps this really 
means that the MAY in 2.3 ought to be a SHOULD, and just be done with 
it. That's certainly the easiest change to make. The more I think 
about this as I write this note, I think that's the correct change to 
make -- MAY in 2.3 becomes SHOULD.

There's a related issue here, too, and that's dealing with the 
compression preference. If you *don't* implement compression, you 
have to start marking your certs with a compression preference that 
says you don't speak compression. If you don't, people will send you 
compressed messages that you can't uncompress. Should this be an 
implementation note?

	Jon

---

From: Michael Elkins <[email-masked]>
Date: Wed, 21 Jul 1999 14:43:02 -0700

> make -- MAY in 2.3 becomes SHOULD.

Given that whether or not an implementation decides to implement compression
can affect its ability to interoperate, I think it would be better to have
the stronger suggestion that it be implemented.  Think "you SHOULD implement
this unless you know what you are doing and can accept the fact that your
implementation will likely not interoperate."

> compressed messages that you can't uncompress. Should this be an 

I beleive it should be since the decision to not support compression doesn't
mean that you can just ignore the issue all together if you hope to talk to
anyone else besides yourself.

me

---

From: Adam Back <[email-masked]>
Date: Wed, 21 Jul 1999 23:27:46 +0100

> implementation will likely not interoperate."

Couldn't something be done about this with a capability in the public
key?  ie as with mixmaster you don't send people compressed messages
if they can't decompress them.

Adam

---

From: Jon Callas <[email-masked]>
Date: Wed, 21 Jul 1999 19:03:56 -0700

At 2:43 PM -0700 7/21/99, Michael Elkins said:

[...]

Noted. You're right. I'll make it be a SHOULD in 2.3 and put in some 
expository text, related to the things we've written here.

	Jon