Hi,
poiboy(_at_)SAFe-mail(_dot_)net writes:
The question seems to focus on whether 'a valid OpenPGP message' (above) means
"one and only one OpenPGP message" or "only valid OpenPGP messages." For
implementation purposes, I'm guessing that the first interpretation best
describes what happens in practice:
ENCRYPTED( LITERAL )
ENCRYPTED( LITERAL, LITERAL, LITERAL )
ENCRYPTED( COMPRESSED( LITERAL ) )
ENCRYPTED( COMPRESSED( LITERAL, LITERAL, LITERAL ) )
In other words, compressed messages don't share the same "level" with any
other
message (including another compressed message) and compressed messages "wrap"
only a single message at a time (granting that a list of literal packets
comprise a single literal message). FWIW, my implementation accepts a list of
any sort of messages in the encrypted body (which could lead to really funky
output) but will only create encrypted messages as ENC(CMP(MSG)) or
ENC(MSG).
Part of the problem is the encoding of compressed messages. RFC1991
claims that compressed packets have indefinite length, so there is no
way to know when the packet "ends". As a result, the parser couldn't
differentiate between the end of a compressed packet and a subsequent
packet. That meant it was necessarily illegal to have:
ENCRYPTED ( COMPRESSED ( LITERAL ) | COMPRESED ( LITERAL ) )
because you oculdn't tell when the first compressed packet ended and
the second one began (because you've got a length-of-length of 11,
meaning indeterminate).
RFC2440 changed this to allow compressed packets to have a determined
indeterminate length, so you could tell when the packet ended without
knowing it's length a priori. So, technically you COULD, using
RFC2440 syntax, implement the aforementioned encryption of two
compressed messages.
The key is being able to tell when the first packet ends and the
second one begins "above" the packet-type processor. In other words,
just because gzip can tell you when the data has ended, that is not
sufficient for the PGP Packet Processor.
So I believe it is legal to have the any of your suggested
combinations, as well as multiple compressed packets, IFF you use the
RFC2440 partial-packet length encodings instead of the RFC1991
indeterminate length encoding.
I'm not sure offhand what the various implementations allow. ISTR
that the PGP 5/6/7/8 parser will happily accept this construction.
<chair hat>
Question to the audience: Do we need any changes to the text
to make this more clear?
</chair hat>
Aloha,
poiboy
-derek
--
Derek Atkins 617-623-3745
derek(_at_)ihtfp(_dot_)com www.ihtfp.com
Computer and Internet Security Consultant