My personal biggest wish list item is one we have discussed before. We
need to do something to make OpenPGP easier to implement. IMO we need
to rationalize and simplify our data structures. Too many warts have
grown up over the years in the name of backwards compatibility and
over-optimization.
I see two directions we could go. The first is to specify an OpenPGP
subset. We would remove as many of the alternative ways of doing things
as possible: "Old" packet headers. String2Key specifiers other than
salted+iterated. Non-MDC'd encryption packets. Unprefixed symmetrically
encrypted packets. Signature packets without 1pass headers.
The goal is to create a subset of OpenPGP which is backwards compatible in
that messages created in this subset can be read by old OpenPGP clients,
but not vice versa. The most widely used OpenPGP clients that participate
here can be updated to only create in the subset. Then new implementors
can ignore some fraction of the spec, making their job somewhat easier.
However as the list above illustrates, this only gets us so far. We need
to consider the essence of OpenPGP as being the options and crypto, and
not the specific data formats. Imagine the set of transformations that
could be executed reversibly by a straightforward program that converted
between traditional and simplified formats. It would not understand crypto
at all, but it would just do a reversible transformation into some other
form. Of course it could not change the plaintext of encrypted packets,
but imagine that this transformation program could be hooked into the
encrypt/decrypt pipeline and apply as well to plaintext.
My point is that creating a new OpenPGP format which is interchangeable
with the current one via such a program would not be a semantic change to
the OpenPGP spec, merely surface syntax. I am not proposing that such a
program would exist, rather that the existence of such a transformation
would guide and constrain the kinds of syntactic changes we should
consider.
This would allow us to get rid of the whole concept of old and new packet
headers, and instead define a simple and extensible header concept, that
can support either prefixed-length or dynamic-length packets. We can
fix our other data structures to simplify parsing and packet creation.
The hodgepodge of different ways of specifying lengths, the kludges
related to secret key packet encryption, over-optimized bitfield packing,
can be streamlined.
I don't see creating a new specification based on these principles
as an enormous task. It is merely another way of encoding the same
information that is already described in the spec. Ideally we could
make this change independently of other proposed extensions to OpenPGP
semantics or cryptography.
Several problems remain. How would we make a transition to using a
new and completely incompatible format? And what about legacy messages
and keys? Some keys have expiration dates decades in the future; key
signatures using current packet formats were expected to retain their
validity for that long. We can't change packet formats on signed data
without breaking signatures.
These appear solvable. We can handle the switchover exactly as we have
handled the introduction of other incompatible changes such as new packet
types. At first we support both versions and create one or the other kind
of message depending on clues about the recipient, like the vintage of
his key. At some further point we start using the new formats 100%.
As far as legacy data: First, expectations of multi decade validity of
signatures may be unreasonable due to the inherent relative weakening
of cryptography as time passes. In practice it may be acceptable to
demand that signatures get re-issued periodically to confirm their
validity. However in the mean time we would still have a number of years
in which such expectations would be arguably more reasonable, and we
cannot realistically just start ignoring today's signatures any time soon.
In that case it may be helpful to consider the transformation program I
described above not just as a figure of speech to motivate the distinction
between semantics and syntax, but as an actual tool. Perhaps an open
source version of such a program could be created and distributed
which could turn an OpenPGP message of one format into the other. Then,
keys and signed messages could be transformed into the new format and
stored in that way, and when it was time to verify them they could be
automatically transformed back.
Well, this message has become quite a bit longer than I intended. I don't
claim to have all the answers, and there may be other objections which
make the idea untenable. But if we think of this standard as something
which will last for decades, as I would suggest we should, maybe it makes
sense to make changes now which will bring benefits for many many years
to come.
Hal Finney