On Mon, Nov 14, 2005 at 02:46:26PM -0800, Jon Callas wrote:
In 5.13. Sym. Encrypted Integrity Protected Data Packet (Tag 18), the
phrase:
"(often literal data packets or compressed data packets)"
should probably be:
"(often a literal data packet or compressed data packet)"
since we no longer allow multiple literal packets in a row.
Changed.
Actually, can it be anything else? Most OpenPGP parsers would understand an
arbitrary nesting of compressed, encrypted and MDC-protected encrypted
packets, but does that make sense?
I can see a different use for it, however. Being a bit uneasy about the
secret key packet format (Packet tag 5, Section 5.5.1.3.), I think, it is
ultimately up to the implementation, how they store and protect private
keys, as it does not affect interoperability, as long as private keys can be
exported and imported in a common format.
Some text about this should be added to 5.5.1.3., in my opinion, stating that
implementations SHOULD be able to export and import private keys in this
format. It is the more important, as the passphrase-protected version is
vulnerable to the Klima-Rosa attack. I am hesitant whether to say that they
MAY store them in this way (as most actually do) or would it be more
appropriate to say that new implementations SHOULD NOT do that.
For secure storage and transmission of private keys, one could put a
private key packet (tag 5) without passphrase protection into an
MDC-protected encrypted packet (tag 18), maybe with compression in between.
This would thwart the Klima-Rosa attack, while not requiring dramatical
changes to the standard.
But again, I think that the storage format of private keys needs not be
standardized. For example, our ePointPGP tool (see
http://pgp.epointsystem.org/tool-help) generates private keys directly from
the passphrase, without storing them in any way. Yet, it is fully
interoperable with many other RFC2440bis implementations on the message
and public key level.
--
Daniel