ietf-openpgp
[Top] [All Lists]

case for removing subpacket type 10

1997-11-23 08:23:38

Bill Stewart <stewarts(_at_)ix(_dot_)netcom(_dot_)com> writes:
So the Infamous Additional Recipient Request is just a subpacket of
known length, in a table of zero or more extension-like subpackets,
and the description of the Criticality Bit seems to imply that it's
ok to have subpacket types that aren't recognized and can be skipped
over because their lengths are known.  So that's the good news.

Seems to me that there is no problem at all just removing subpacket
type 10 (the ARR/CMR subpacket).  The draft already says that if an
unrecognised subpacket is present in a self signature that it will be
ignored.  This is obviously needed to allow backwards compatibility
when new subpackets are introduced.

OK: so I call for subpacket 10 to be removed.  Anyone else?

The bad news is that, while the Criticality Bit is only sketchily
documented, it sounds like part of a CMRist plot, to make use of the
ARR mandatory if the recipient requests it

I see the problem -- ouch -- if a vendor choses to, they can make
their software mark ARRs as critical and old software will say that
the self signature failed.  Which could result in the software not
using the key.

I think the fact that doing so introduces compatibility problems
protects us from this happening, a vendor's corporate customers may
get irate when they are unable to communicate with OpenPGP compliant
implementations due to such a purposely introduced incompatibility.

(there _is_ the semantics issue of what the program should do if it
understands the Additional Recipient Request and doesn't feel like
cooperating :-)

Well a cypherpunk or pro privacy advocate's PGP patch / implementation
can do one of a number of things:

a) as a special case ignore the criticality bit if combined with
   subpacket type 10 (ARR/CMR)

b) pretend to capitulate with the "request" and stuff garbage in the
   extra PKE field instead of the session key; this will fool a policy
   enforcer policeman software which doesn't have the private key.

c) capitulate and include a valid extra PKE field but automatically
   super encrypt to the real key holder only (optionally pad with a
   bit of garbage and white space to allow easy reconstruction with
   cut and paste, but to make auto detection difficult).

Adam