At 02:51 PM 1/25/98 +0000, Ian BROWN wrote:
ARR subpacket - This will be defined as optional.
The draft will say explicitly that the implementation
can do anything it wants with this. It does not
have to use it.
I was surprised, to say the least, to see this in the minutes of the December
meeting. In the weeks running up to the standard, extensive discussion over
this topic occurred. An almost complete consensus formed around the view that
subpacket 10 should be "reserved for future/PGP use" with no other comment.
This is a compromise solution that allows PGP Inc. to persue their message
recovery scheme while retaining compatibility with other implementations that
do not.
As Ian Grigg said, there is certainly no consensus within the WG that this
feature should be included. It should therefore not be "blessed" by
documentation within the standard.
Fundamentally, your choices are to
- leave the structure that way (either documenting it or not), or
- define some alternate required behaviour for #10, like reject the key
(which is identical to the behaviour with the critical bit set :-)
or display an error message or mail the ARR key to aclu.org, or
- replace the while subpacket structure with something completely
different, forcing PGP to be non-compliant and to use some other
extension mechanism for the evil option. (Basically unacceptable.)
The ARR stuff was explicitly designed so that implementations that didn't
want to implement it could ignore it safely; it's hard to undo that.
Leave it alone for the standard, or perhaps also define a SHOULD
error message for unsupported subpacket types.
Thanks!
Bill
Bill Stewart, bill(_dot_)stewart(_at_)pobox(_dot_)com
PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639