tzeruch(_at_)ceddec(_dot_)com writes:
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".
Things like secret keyrings are largely beyond the scope of the spec
because it describes interchange formats. We do describe secret keys
since those could be exchanged, as when someone brings his secret key
from work to his home.
There are many places in the spec where backwards compatibility
considerations are called out. In some places we have a SHOULD behavior
which breaks backwards compatibility, with an associated MAY behavior
to retain backwards compatibility.
Ultimately it is for the implementor to decide how important backwards
compatibility is with PGP 2.X.
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.
By "normalization" do you mean the problem of assembling packets which use
partial-length fields? If so, it was for this reason that I recommended
adopting a four-byte length field option. I understand this will be
discussed at the OpenPGP meeting tomorrow.
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 agree that the bit-twiddling which has called so much attention to
itself is a tiny fraction of the work you must do to implement the spec.
I would make all of these MUSTs, but embedded applications may have
reasons not to, and I can normalize the stream myself.
What exactly would you make MUSTs? Do you mean you would disallow the
partial-length packets?
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.
I don't understand the significance of this definition. What is it about
normal vs non-normal streams which requires them to be treated differently?
I could see a distinction between packets which have the length at the
beginning vs packets whose length is not known until you have read the
whole thing. But I don't understand why the issue is whether the
partial length packets are less than 4096 bytes.
Hal