Re: [openpgp] Guidance for Designated Expert?

[Daniel Kahn Gillmor <[e-mail]>]

On Sun 2023-02-05 12:26:46 -0500, Daniel Kahn Gillmor wrote:
> A baseline proposal (sorry it's not yet a patch), is for the guidance to
> say that the Designated Experts should be given substantial leeway, but
> they should:
>
> - avoid codepoint squatting and vanity registrations
>
> - require that the specification is concretely useful
>
> - require that any registered algorithms meet the security requirements
>   of the community and the message structures for which they are
>   proposed to be used.

I've just knocked together
https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/232, which
adds text to the IANA considerations section:

------------
--- a/crypto-refresh.md
+++ b/crypto-refresh.md
@@ -3331,6 +3331,31 @@ Because this document obsoletes {{RFC4880}}, IANA is requested to update all reg
 OpenPGP is highly parameterized, and consequently there are a number of considerations for allocating parameters for extensions.
 This section describes how IANA should look at extensions to the protocol as described in this document.
 
+Most of these registries have been moved the SPECIFICATION REQUIRED method.
+As indicated in {{RFC8126}}, the designated expert is expected to ensure that a clear and detailed specification capable of producing interoperable implementations is permanent and readily available.
+Because interoperability in the store-and-forward domains where OpenPGP most often used is made more challenging by combinatorial explosions of options, and because many of these registries are limited in size, the designated expert is expected to minimize codepoint squatting and vanity registrations by taking the following steps:
+
+- Ensure that the specification is concretely useful.
+  Does a clear use case exist?
+  Is that use case *not* handled by any existing mechanism in OpenPGP?
+  Is the referenced specification fit for purpose for that use case?
+
+- Ensure that the specification is complete.
+  Does it describe the expected semantics or behavior when the proposed codepoint is present?
+  (For example, when adding a new elliptic curve, are all tables referencing the curve populated as expected?)
+  Do the expected semantics or behavior when the codepoint is *not* present conform to existing baseline deployments?
+  Does the specification identify *where* the codepoint is expected to be observed?
+  (For example, when designating a new signature subpacket, does the specification indicate which types of signature it is to be found in?)
+  Does the specification clearly identify the expected semantics or behavior when the code point is observed in unexpected places?
+
+- Ensure that the specification and its use case is not contradictory to existing registered codepoints.
+  Can the the specification or its deployment produce confusion or interoperability failures when it is observed in combination with some other mechanism in OpenPGP?
+
+- Ensure that any registered algorithms meet the security requirements of the community and the message structures for which they are proposed to be used.
+  When a novel cryptographic approach is considered, is it strong enough to be worth deploying?
+  Are there enough diverse expressions of interest to determine a sense of the security needs of the community that would adopt the feature?
+  Does the proposed algorithm meet those security needs?
+
 ## New String-to-Key Specifier Types
 
 OpenPGP S2K specifiers contain a mechanism for new algorithms to turn a string into a key.
------------

I'm sure it's imperfect, but i'm offering it as a basis for discussion.

What guidance do you think the designated expert should follow when
considering a codepoint registration?

        --dkg