Re: Obvious (?) question about interoperability

[nospam-seesignature@xxxxxxxxxx]

On Wed, 1 Apr 1998, Jon Callas wrote:

> At 6:11 PM -0800 3/31/98, nospam-seesignature@xxxxxxxxxx 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 ---