[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Obvious (?) question about interoperability
At 6:11 PM -0800 3/31/98, nospam-seesignature@xxxxxxxxxx wrote:
Having just regrouped my PGP 2.6.x support stuff, I need to ask what
versions of what types we need to support.
One stalling point is that although there are V4 packets for thinks like
key material, 2.6.2 will only like RSA keys in V3 packets.
Generally PGP 5.0 will interoperate, except any secret keyrings won't be
decryptable in OpenPGP (because of the loss of type 3 Iterated S2K being
replaced by type 4). It will also cause problems for conventionally
We're going back to the type 3 iterated-salted s2ks. Simplicity is a
virtue, but not when it makes things harder.
So I have to pause and ask, How backward compatible need we be, and with
what versions? Should 2.6.x be a mode, or something which prevades every
portion of the spec where "We do X every time, except we also need to
leave Y in".
The charter calls for "limited" backwards compatibility. I think for your
purposes it depends on how much you want to do. Our predecessor, RFC 1991,
recommended backwards compatibility to one previous version. That would
mean you could ignore 2.6. That wouldn't particularly nice, though. There
are a number of things you can do that are easy to make things work with
I am planning on putting in the algorithm notes that a V3 key with a V3
self signature MAY be considered to have an implicit preference for IDEA
alone. This would mean that a considerate OpenPGP implementation can freely
interoperate with 2.6, but a minimal one doesn't have to.
For you, do as much as you want above what is required. If you want your
implementation to be widely used and interoperable with old versions, you
can do a lot. Otherwise, you can leave the annoying stuff to someone else.
Another problem I have is with the new CTB, at least for intrinsically
short packets like keys, signatures, P/SKESK headers, etc.
If these are normalized (Monolithic if overall length is <4096 bytes), I
can use ordinary libc calls (fread, fwrite). Otherwise I need a
normalization pass. I think implementations SHOULD store anything except
compressed, literal, or conventionally encrypted packets in normalized
form. Further, the conventionally encrypted packets should not divide the
first 10 bytes (actually 11) of the stream.
There has been a suggestion for a new-format length that would use the
length byte of 0xFF (which would ordinarily be a stream-chunk of 2GB) as a
marker for a four-octet length that follows. So you would see:
as a packet form. That lets someone bring in the whole packet without the
streaming mechanism. People sounded supportive of that, and my slides for
tomorrow have that on there as a feature I want to have in the next draft.
Jon Callas jon@xxxxxxx
CTO, Total Network Security 4200 Bohannon Drive
Network Associates, Inc. Menlo Park, CA 94025
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
665B 797F 37D1 C240 53AC 6D87 3A60 4628 (RSA)