Werner Koch <wk(_at_)isil(_dot_)d(_dot_)shuttle(_dot_)de> writes:
Adam Back <aba(_at_)dcs(_dot_)ex(_dot_)ac(_dot_)uk> writes:
you to draw the line at this kind of thing. It seems that pgp-2.6.x
formats were not designed with enough forward compatibility in mind to
allow doing this kind of thing without resorting to overloading
This is true for the implemenations of pgp2.x but not for the
packet format as described in the rfc.
Ah yes, but PGP 2.6.x isn't quite RFC 1991 compliant, in that it falls
over in a heap when it should report that a new version is required,
or that a particular signature can not be checked, or whatever other
graceful recovery is specified in the circumstances.
Your g10 implementation appears to be the only implementation which is
paying much attention to rfc1991, and pgp-2.6.x is by far the largest
deployed base -- larger than pgp-5.x and g10, and Tom's
implementation.
So backwards compatibility with what pgp-2.6.x does I think should be
viewed as more important than backwards compatibility with
rfc-1991.txt.
This format is as extensible as OpenPGP (see algorithm identifiers
and reserved values in the header) although there are some problems
with the grammar of the packet sequence. There is no reason for a
PGP 2 program not to work with other rfc1991 implementations, it
should just print a warning that that and that algorithm is not
supported and decryption/verification is not possible.
There are other implications I think, such as saying that it can not
verify a signature (which is say DSA or Elgamal) rather than refusing
to process the whole message. In any case pgp-2.6.x doesn't do either
of these things generally, I think.
Adam
--
print pack"C*",split/\D+/,`echo "16iII*o\U(_at_){$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`