-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
"David Shaw" <dshaw(_at_)jabberwocky(_dot_)com> writes:
The ONEPASS method can also easily handle such constructions as
ONEPASS+OBJECT+OBJECT+OBJECT+SIG, which SIG+OBJECT cannot.
... [to which I replied, and then he replied again:]
It's not clear whether it is permitted now or not.
...
The general question of multiple packets (whether in a one-pass
signature, compressed data packet, or encrypted data packet) is
somewhat hazy in the draft. Speaking only about literal packets for
now, sections 5.6, 5.7, and 5.13 all say yes (using the plural
"literal data packets"). Section 10.2 says no.
Those sections refer to sequences inside compressed and the two
flavors of encrypted data packets (respectively), not signatures.
My claim that this is not allowed for signatures was based on the
grammar in 10.2.
...
Come to think, your suggestion of using a compressed data packet to
encapsulate could be useful here as well:
ENCRYPTED(COMPRESSED(LITERAL+LITERAL)).
Yes, it's pretty clear that this is legal. The grammar doesn't
cover the contents of compressed packets, so the language in
section 5.6 would seem to govern. (Curiously, that section
suggests that COMPRESSED packets might live directly in
signatures, which is what kicked off this whole discussion.)
I don't really think that sequences of LITERAL packets are a good
thing. I really don't like them for general archiving, as they don't
carry nearly enough information. I also see no reason to avoid using
an external archiver (tar, zip, or any of many others). I was going
to argue against allowing sequences of LITERAL because they complicate
decryption: implementations will likely want to provide a user
interface to control which LITERALs should be processed. But then,
David pointed out that we already have this problem inside COMPRESSED
packets. I'd be happy to withdraw that ability, but I'm sure others
will object, so I'll admit defeat in advance.
[Note that one can always encrypt each file separately, and if you're
worried about the public-key encryption cost, your implementation
could reuse the session key (but not IV) during multiple-file
encryption, and recognize that case on decryption. I'm not advocating
this -- I prefer using a real (external) archiver instead -- but
simply pointing out an option that would be "conservative in what you
generate".]
-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.3
iQA/AwUBPywhaec3iHYL8FknEQK7KgCg+o9TKREgePvovRFhSNYP+Uze1IsAn0hW
yHRBYP/QoAZHfEFayhrg1iqm
=lgjq
-----END PGP SIGNATURE-----