I can create a conventional encryption key using S2K by itself on a
passphrase, but I can also encrypt a conventional key using a S2K on a
passphrase.
Yes, the second mode allows a message to be encrypted with a session
key, with multiple ESK packets preceding it which provide that session
key in different ways. The session key can be public-key encrypted
to various keys, and/or the session key can be secret-key encrypted to
various passphrases.
If it is simply a conventionally encrypted message, this level of
indirection is not required and you can use the S2K hash of the passphrase
as the session key directly, which is the first mode.
In the section beginning:
"The decryption result consists of a one-octet algorithm..."
Shouldn't there also be a two-octet checksum after the random key material
(to be identical to what is public-key encrypted)?
The purpose of a checksum is to tell you whether you've entered the
right passphrase. That's not necessary here because after decrypting the
session key (SK) it will immediately use that SK to decrypt the message,
and there is a check which is done in the first 10 bytes of the message
to see if the SK is correct.
It is true that the public key ESK packets do have this checksum, so you
are correct that it would be more consistent to have them for the symmetric
ESK as well, but functionally they are not needed.
[BTW, Jon, I notice that the wording in section 5.3 still uses the old
term Conventional Encrypted Session Key in a few places.]
Hal