Re: [openpgp] Guidance for Designated Expert?

[Paul Wouters <[e-mail]>]

On Tue, 7 Feb 2023, Daniel Kahn Gillmor wrote:

> 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.

Most registries have been updated to use a Specification Required policy.

> +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?

I don't think these are very relevant for specification required. All
that is really needed is that the specification is complete enough for
implementors to be able to implement this. Whether a "use case" is
covered or not is very subjective.

> +- Ensure that the specification is complete.

Right.

> +  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?)

Makes sense, although it feels like just an example of "specification is
complete"

> +  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?

I am not sure about these. I would probably formulate it more
generically. Eg If the code point is a modular extension that adds a new
feature that is okay. If the code point would modify existing behaviour,
it should probably be IETF stream RFC required. (eg if it Updates: the
core spec by modifying its behaviour)

> +- Ensure that the specification and its use case is not contradictory to existing registered codepoints.

I don't know what this really means.

> +  Can the the specification or its deployment produce confusion or interoperability failures when it is observed in combination with some other mechanism in OpenPGP?

This comes down to the above. If it is a modular extension, a new
feature that is independent of the existing features, or just a new
algorithm or cipher, then it would be fine. This would not require
Update:ing this draft. If it wants to update this draft, it must be
by standards action RFC required.

> +- 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?

I'm not sure I agree with all of this. For example "requirements of the
community" might be hard for nation state ciphers, where the community
doens't really see a point or cannot prove it means any security
standard. If Wakanda wants its vanity cipher Foo, and we have no idea
about Foo's security properties, we should still let them have the
code point and use it.

Paul