On Wed, 1 Apr 1998, Jon Callas wrote:
At 6:11 PM -0800 3/31/98, nospam-seesignature(_at_)ceddec(_dot_)com wrote:
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
encrypted packets.
We're going back to the type 3 iterated-salted s2ks. Simplicity is a
virtue, but not when it makes things harder.
So I can rip out type 4 (which I haven't tested). Good. Easy != Simple
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
2.6.
Actually I have code to allow the 2.6 code to handle 2.1 (or whatever
the pre PKCS padding PGP2 was and it may still be in the minipgp README).
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.
Actually I just updated my 2.6.2 libraries and am retaining them as
separate routines since they are fairly short. It would make a
-V3-compatible flag much easier than trying to fiddle with each bit.
------------------
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:
<CTB><0xFF><four-octet-length><packet-body>
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.
NO! NO! NO! IT DOESN'T - I will still have to support the V3, the
degenerate packet length
<0xe0>f<0xe0>o<0xe0>r<0xe0>m<0xe0>a<0xe0>t<0x01>s, and this new one.
I can't magically force all messages sent to me to use this new format.
Actually, I don't object to the new packet above, at least not until I
think about it. Remember that ADDING anything for one implementation will
require all other implementations to support it or not be able to read it.
What I object to is what I did with the <0x07>formats string above.
Perfectly valid. Pefectly horrid.
I want a rule that if the content of a packet is less than the maximum
terminal packet size (8192+192? bytes), then it MUST NOT be split up.
Barring that (for small memory or something), that the first
partial-packet-length must encompass any header information and at least
one byte of data (i.e. the 10 byte startup encryption packet, or the
entire literal header for literal packets).
That way I can use fread instead of another layer to extract the data from
the packet-length bytes.
--- reply to tzeruch - at - ceddec - dot - com ---