ietf-openpgp
[Top] [All Lists]

Re: Obvious (?) question about interoperability

1998-03-31 23:30:22
At 6:11 PM -0800 3/31/98, nospam-seesignature(_at_)ceddec(_dot_)com 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
   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 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
2.6.

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:

        <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.

        Jon



-----
Jon Callas                                  jon(_at_)pgp(_dot_)com
CTO, Total Network Security                 4200 Bohannon Drive
Network Associates, Inc.                    Menlo Park, CA 94025
(650) 473-2860
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)



<Prev in Thread] Current Thread [Next in Thread>