That leaves us with the fourth option. Say nothing and do not document it.
This of course will be problematic for programmers, as they test their
code against 5.x, and discover the strange packets.
It may be that it doesn't cause a problem.
Jon's done a great job on the standard - I still find it hard to read,
partly because it's bottom-up rather than top-down, which makes it
easier to follow syntax and harder to follow semantics, and partly because
there's just a _lot_ of detail, and the newer features are pretty complex.
But if I do understand what's going on, the CMR support is just one entry
in a table that's needed anyway, plus a paragraph of apologies (:-),
and may be the primary motivation for one other feature.
If I can modifiy Jon's syntax description a bit:
A Packet is a record containing the following in a tersely encoded format (:-)
Packet Tag - indicates packet type, 0-15 (old) or 0-63 (new)
Packet Length - optionally indeterminate
Packet Body - format and semantics depend on Packet Tag
A Transferable Key Packet probably has Public Key syntax Packet Tag = 6?
A Transferable Key Packet has
One Public Key Packet
Zero or more revocation signatures
One or more User-ID-With-Optional-Signatures entities
Zero or more Subkey-With-Signature entities
["entity" isn't a PGP Packet format,
it's a group of packets I've defined for
increased syntactical precision]
A User-ID-With-Optional-Signatures entity is
One UserID Packet
Zero or more Signature_Packets
[Semantics: These signature packets each sign the
concatenation of the public key, the user id, and signature
info.]
A Subkey-With-Signature entity is
One Subkey Packet
Maybe[??] zero or more subkey revocation packets[??]
One or more Signature_Packets
[Semantics: These signature packets each sign the
concatenation of the public key, the subkey, and signature
info.]
A Signature_Packet is a packet with PacketTag=2,
either Version 3 or Version 4 Signature Packet Format
A Version 4 Signature Packet contains
Version Number (octet = 4)
Signature Type (octet - e.g. binary, text, several keycerts,
revocations)
Public Key Algorithm (octet - e.g. RSA, DSA, EG, ...)
Hash Algorithm (octet - e.g. SHA-1, MD5, RIPEMD-160, ...)
Octet Count for following hashed subpacket data (2 octets, weird format)
Subpacket_Data_Entity - gets hashed
Octet Count for following unhashed subpacket data (2 octets, weird
format)
Subpacket_Data_Entity - doesn't get hashed
Left-16-bits-of-signed-hash-value Field - for checking success
Signature - Algorithm-specific collection of multi-precision integers
A Subpacket_Data_Entity - [My term. Draft section 5.2.2.1]
Length-Of-Subpacket-Set (two octets, probably packed format?)
Zero or More Subpackets
A Subpacket - [!!! FINALLY - THE FUN PART !!!]
Subpacket Length - (packed, one or two octets)
Subpacket Type-And-Criticality-Indicator - Octet
Subpacket Body - format is Subpacket Type dependent.
A Subpacket-Type-And-Criticality-Indicator Octet
Bits 0-6 - Subpacket Type, an entry from a table including
2 - signature creation time [And a bunch of similar good
entries]
4 - exportable [This isn't ITAR - this indicates whether
the signature can be transmitted to other people or is
for your own use only. So don't panic :-)]
10 - The Infamous Additional Recipient Request
16 - Issuer KeyID - Sounds Ominous and Not documented!
12 - Revocation Key - Only for self-signatures(??)
so you can revoke your key after losing your key
21 - Preferred hash algorithms
22 - Preferred compression algorithms
23 - key server preferences
24 - preferred key server - presumably the Signer's preference
for finding further data about the Signer's key?
Bit 7 - Criticality Bit - [Semantics: I don't quite understand it?
Reject Key If you don't support the Subpacket Type,
or reject the signature rather than the whole key?]
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.
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 (there _is_ the semantics issue of what the program
should do if it understands the Additional Recipient Request and doesn't
feel like cooperating :-)
The ugly news is that Additional Recipient Requests are a really weird thing
to attach to a signature, rather than part of the key itself -
I suppose that makes it easier for the Corporate Security Bureaucrats to
request,
rather than having some special case part of the key generation, which would
be uglier, but it's still a strange place to put it.
But in conjunction with the Criticality Bit, this extension method is a
Denial Of Service Attack - unless I'm misunderstanding the bit,
if the bit is set and the subpacket type is unrecognized, the recipient
is supposed to reject the entire key packet and not just the signature packet -
does this mean that somebody can sign your key with a Critically Bogus Subpacket
and prevent anybody from using your key? (e.g. by signing a keyserver key...)
Thanks!
Bill
Bill Stewart, stewarts(_at_)ix(_dot_)netcom(_dot_)com
Regular Key PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639