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.
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".
------------------
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.
For all the complaints about bit-twiddling, I don't understand why no one
doesn't think there is any problem creating an entire I/O abstraction
layer, i.e. a pgpfopen, pgpfread, etc. which is what the spec requires (if
you don't want to add it as a filter).
I would make all of these MUSTs, but embedded applications may have
reasons not to, and I can normalize the stream myself.
Since I introduced the term normalized, I should define it -
packet :- oldCTB-len, datachunk... | newCTB len-stream
len-stream :- nontermlen, datachunk, len-stream | termlen, datachunk
The len-stream is normal if it does not contain any nontermlen entries
indicating the following datachunk is less than 4096 bytes.
--- reply to tzeruch - at - ceddec - dot - com ---