Re: [openpgp] rfc4880bis and draft-openpgp-iana-registry-updates-01

[Ronald Tse <[e-mail]>]

Hi Werner,

Apologies for the late response to this. I fully agree with your concluding statements:

> I doubt that it is advisable to merge this into RFC-4880bis because this
> is a request for one time action of the IANA.  

The IANA registries only require a one-time change, and perhaps one-time changes are best not mixed with 4880bis because 4880bis should (probably) be a long living document that helps people implement OpenPGP. Most of them should not be concerned with registry policy changes.

> However a request to
> change from IETF REVIEW to SPECIFICATION REQUIRED is an actual action we
> like to see and that should go into a new RFCs.

The point is that there needs to be a place to:

1. Detail the registry policies and procedures for OpenPGP. These were previously in RFC 4880 (and currently in 4880bis).
2. Detail the changes to the OpenPGP IANA registries requested by 4880bis (such as the addition of the AEAD algorithm registry)
3. Detail the one-time changes to OpenPGP IANA registry (as given in draft-openpgp-iana-registry-updates-01)

I’d like to propose that we keep 4880bis straightforward to read for people who implement OpenPGP, rather than burdening them with IANA registration procedures and one-time changes to the registries.

Specifically,

a) A new document shall detail out all policies and procedures for the OpenPGP registries at IANA. This is easily done by extracting content of #1 and #2 to this new document, while keeping 4880bis about the protocol itself. This document will form a pair with 4880bis moving forward.
b) draft-openpgp-iana-registry-updates will handle the one-time changes (#3)

Thoughts?

Kind regards,
Ron

_____________________________________

Ronald Tse
Ribose Inc.


> On Oct 24, 2018, at 12:34 AM, Werner Koch <[e-mail]> wrote:
> 
> Hi!
> 
> The recently expired draft-openpgp-iana-registry-updates-01 specifies
> one of the goals of the WG to make the assignment of new identifier etc
> easier.  I am not sure whether this drafts can be integrated into
> RFC-4880bis but the IANA Considerations section in RFC-4880bis needs
> anyway a rework because the demanded registries are existent and only
> need to list new items. 
> 
> I am not sure how to do this.  For example RFC-4880 reads
> 
> --8<---------------cut here---------------start------------->8---
>  10.1.  New String-to-Key Specifier Types
> 
>   OpenPGP S2K specifiers contain a mechanism for new algorithms to turn
>   a string into a key.  This specification creates a registry of S2K
>   specifier types.  The registry includes the S2K type, the name of the
>   S2K, and a reference to the defining specification.  The initial
>   values for this registry can be found in Section 3.7.1.  Adding a new
>   S2K specifier MUST be done through the IETF CONSENSUS method, as
>   described in [RFC2434].
> --8<---------------cut here---------------end--------------->8---
> 
> What I did until now was to replace RFC REVIEW (aka IETF CONSENSUS) by
> SPECIFICATION REQUIRED and to reference RFC-8126.  See the gitlab
> repo. The draft-openpgp-iana-registry-updates-01 has this text
> 
> --8<---------------cut here---------------start------------->8---
>  5.1.  PGP String-to-Key (S2K) Registry
> 
>   Proposed changes to the registry:
> 
>   o  Rename the registry to "OpenPGP String-to-Key (S2K) Algorithms"
> 
>   o  Change registry policy to *Specification Required*.
> 
>   o  Update its "Reference" to also refer to this document.
> 
>   o  A Standards Track document is required to register an S2K
>      algorithm with the value "Yes" in any recommendation.
> 
>   Add the following note:
> 
>   Note: Experts are to verify that the proposed registration
>   provides a publicly-available standard that can be implemented
>   in an interoperable way, with notable benefits for the wider
>   OpenPGP community.
> 
>   Update the following registrations:
> 
>   +---------+--------------------+-------+-------+--------------------+
>   | ID      | S2K Type           | REC-S | REC-I | Reference          |
>   +---------+--------------------+-------+-------+--------------------+
>   | 0       | Simple S2K         | No    | Yes   | Section 3.7.1.1 of |
>   |         |                    |       |       | [RFC4880]          |
>   | 1       | Salted S2K         | No    | Yes   | Section 3.7.1.2 of |
>   |         |                    |       |       | [RFC4880]          |
>   | 2       | Reserved           |       |       | Section 3.7.1 of   |
>   |         |                    |       |       | [RFC4880]          |
>   | 3       | Iterated and       | Yes   | Yes   | Section 3.7.1.3 of |
>   |         | Salted S2K         |       |       | [RFC4880]          |
>   | 4-99    | Unassigned         |       |       |                    |
>   | 100-110 | Private or         |       |       | Section 3.7.1 of   |
>   |         | Experimental Use   |       |       | [RFC4880]          |
>   | 111-255 | Unassigned         |       |       |                    |
>   +---------+--------------------+-------+-------+----------------
> --8<---------------cut here---------------end--------------->8---
> 
> I doubt that it is advisable to merge this into RFC-4880bis because this
> is a request for one time action of the IANA.  However a request to
> change from IETF REVIEW to SPECIFICATION REQUIRED is an actual action we
> like to see and that should go into a new RFCs.
> 
> Any hints on how to proceed?
> 
> 
> Shalom-Salam,
> 
>   Werner
> 
> 
> -- 
> Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.