Daniel A. Nagy wrote:
In order to design a successor to v4 key packet format, it is important to
first identify its shortcomings. Here's a list of my problems with it:
Perhaps a pass at listing the problems in v4 ** would
be a fair first phase. Here's a couple of issues
(although I admit to not bit-peeping as much as I
should, most of these are user/mgr level grumbles):
5. Too many integers and formats and what have you.
There should be a base level of formats which should
cover all requirements, and these should be flexible
enough to do that job, while simple and short enough
to be easily implementable and understandable.
6. PGP's feedback mode. There's no point to this.
It's a thing that PRZ added in because he thought it
was cool; he was wrong on that point && and it would
make matters easier if the standard CBC modes that
are described in all the textbooks were used.
7. Cipher suites, not algorithms. Although I like
OpenPGP's tradition of opening up to experiments in
algorithms and so forth, I think it is a pain for
interoperability and implementation. It might be
fine to demand the "right" to implement odd-length RSA
with Ripem-666 hashes and the latest chinese cipher
feedback modes over GOST encryption, but this is
just plain stupidity at the software engineering
level.
As much as possible, I'd suggest that a cipher suites
approach be used: Cipher suite #1 should fix the
PK, the encryption algorithm, the hash, the feedback
modes, and all that. When something breaks, deprecate
the whole sodding lot, and move on to #2.
Life was really good in the days up to pgp2.6. Then
it all went to pot. We may never go back to those
simple times, but we can attempt to simulate it by
using cipher suites $$.
(some of these points are contradictory at some
level :-)
iang
PS **: if we are going to start discussing futures like
v5, it might be easier to stick something in the subject
so people know quickly that it does not effect the
current doc.
PS &&: This is not a criticism of him; nobody ever
builds a perfect cryptosystem, and it falls to later
disciples to carefully clean out the mistakes.
PS $$: Allowing experimental cipher suites would be
fine. Another trap to avoid is the SSL cipher suite
rabbit explosion ... but that should be easy to do
if we allow people to experiment with their own and
only promote the really useful, strong ones. I.e.,
rejection of marginal improvements as a routine.