[openpgp] Insufficient guidance for IANA registry management

[Andrew Gallagher <[e-mail]>]

Hi, all.

There are quite a few code points in the IANA OpenPGP registries that are marked “Reserved” with little or no explanation. They all have references to RFC9580, which is the source of the registry data, but the RFC is not always forthcoming about the reasoning behind their reservation.

Some code points are reserved for future use and can presumably be un-reserved once a draft spec is finalised. Others are reserved to avoid incompatibility with deprecated or experimental features and presumably should not be reused. Some may have been reserved for speculative features that were never implemented and so may be more appropriately classified as “unassigned". It is not always clear which case is which, or under what conditions an un-reservation should be performed.

Reserved code points with sufficient documentation and references (IMO):

* Packet type 19 (MDC)
* Symmetric key algorithms 253-255 (compatibility with s2k usage)
* Public key algorithm 20 (ElGamal encrypt/sign)
* Signature type 0xFF (anti-malleability)

Reserved code points that are documented somewhere but not properly referenced in the registry:

* Packet tag 20 (librepgp)
* Signature subpacket type 10 (marked “placeholder”; effectively reserved for ADK)
* Signature subpacket type 34 (rfc4880bis aead algos, deprecated)
* Signature subpacket types 37 and 38 (1pa3pc, key block)
* Feature flags 0x02 and 0x04 (librepgp)
* Key flag 0x0004 (ADSK)
* Symmetric key algorithms 5 and 6 (RFC2440)
* Hash algorithms 4-7 (RFC2440)

Reserved code points without documentation, but with obvious intent:

* Various zero encryption algorithm IDs (for consistency with 0 == “unencrypted”)
* Hash algorithm 13 (presumably SHA3-384)

Unclear:

* S2K type 2 (was this iterated+UNsalted S2K?)
* Packet type 0 (strongly forbidden, without explanation)
* UAT Subpacket Type 0 and Encoding Format 0 (was this just a distaste for zero values?)
* Signature subpacket types 0, 1, 8, 13-15, and 17-19 (unallocated in RFC2440, but reserved in RFC4880)
* Key flag 0x0008 (timestamping)
* Public key algorithms 21, 23 and 24 (X9.42, AEDH, AEDSA)

It would IMO be preferable to add a reference to documentation of these code points (this does not need to be an RFC or even an I-D, just a stable URL), or failing that to explicitly state in the registry itself the intent of the reservation. In the signature subpacket registry, it may also be appropriate to revert some of the unused reservations to “unallocated”, if it can be determined that they were never used.

There are also a number of unassigned gaps in the registries that are not specifically marked as reserved, but which are presumably intentional:

* Packet type 15 is the only unassigned code point that can be represented in legacy framing so was presumably kept available for emergencies - but why is 16 also left unassigned?
* Why are public key algorithms 4-15 left unassigned?
* Why the gap in the reason for revocation registry?
* The gaps in the Signature Types registry are obviously for grouping into sub-ranges with similar semantics, however they are not formally defined, and the 0x4N and 0x5N signature type ranges are not well motivated IMO.

If anyone can shed further light on the intent of the above code points, it would be very welcome. It would also IMO be useful if clearer guidance were provided for the benefit of the IANA experts when evaluating registration applications.

Thanks,
A