[openpgp] On guidance to IANA Designated Experts

[Benjamin Kaduk <[e-mail]>]

Hi all,

We had some discussion in today's session about the changes to the IANA
registry policy currently proposed by the crypto-refresh draft (in
particular, moving most registries from IETF Consensus to Specification
Required policies, see RFC 8126 for the actual procedures).

Tero and I both indicated that the Specification Required policy requires
the presence of a Designated Expert, and that we should give some guidance
to the expert on what they should (or shouldn't) be looking for, and dkg
asked if I could send some thoughts to the list.  (An abbreviated of this
form also went to the in-meeting zulip chat.)

I'm functioning as ghost-editor for draft-ietf-cose-rfc8152bis-struct and
-algs, which has some fairly extensive guidance to the experts on their
role in the ecosystem.
https://datatracker.ietf.org/doc/html/draft-ietf-cose-rfc8152bis-algs-12#section-10.4
covers things like avoiding codepoint squatting and vanity registrations,
requiring that the specification is actually useful, and requiring that
algorithms meet the security requirements of the community and the message
structures for which they are proposed to be used.  It also notes that
experts are being designated experts for a reason, and thus that they
should be given substantial latitude.

This is not the only approach that can be taken in terms of guidance to the
experts (though for OpenPGP I prefer this approach).  A contrasting picture
is given by QUIC,
https://www.rfc-editor.org/rfc/rfc9000.html#name-permanent-registrations
where the experts are mostly tasked with verifying that a specification
exists and is readily accessible (not necessarily that it's useful or
complete).  The default procedure seems to be "shall-issue", with a narrow
list of reasons to block a registration.  This is appropriate in a registry
where there's like 2^62 possible values and not much benefit from
restricting registration, but not all registries are in that situation.
The situation for "provisional registrations" (a few sections previous) is
even more open, with the only reasons to reject a provisional registration
are "for an excessive proportion of remaining codepoint space or the very
first unassigned value"


In short, I feel pretty strongly that we should provide guidance to the
experts, and while I would prefer some "COSE-like" guidance, the WG
consensus should determine what we put in the document.

-Ben