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

From: Ronald Tse <[email-masked]>
Date: Tue, 27 Nov 2018 17:39:38 +0000

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 <[email-masked]> 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.

---

From: "Mark D. Baushke" <[email-masked]>
Date: Tue, 27 Nov 2018 10:22:08 -0800

fwiw: IANA has a document:

https://www.iana.org/assignments/pgp-parameters/pgp-parameters.xhtml

which is used to identify items for Pretty Good Privacy which includes
the RFC 4880 defined numbers as well as a few assigned numbers that do
not have an RFC 4880 reference.

Not that even an IETF Draft *might* end up adding to the pgp-parameters
file if the number used is used in enough implementtions along the way.
Yes, it is best to use the IETF CONSENSUS method for new identifiers a
la RFC2434, but an informational RFC may be used to define de facto
standards that have arisen and may otherwise cause interoperability
problems if not defined.

Creating an RFC to add a new identifer to that IANA pgp-parameters.xhtml
file is not hard and makes sense to do.

There will be a published RFC4880 successor eventually. However, it will
not be a living document. It will be given a particular RFC number nnnn
and then there will probably eventually be an RFCnnnnbis document... etc.

In addition, there is no real problem with coming up with new things to
add to the pgp umbrella as very simple short RFCs. 

	Enjoy!
	-- Mark

---

From: Ronald Tse <[email-masked]>
Date: Wed, 28 Nov 2018 05:00:25 +0000

Hi Mark,

You’re right. IANA has a page of all “Pretty Good Privacy” registries, but even the name of that is outdated and should reflect “OpenPGP” instead.

The intention of "draft-openpgp-iana-registry-updates” was to perform a one-time change for the whole set of OpenPGP registries, to get them up-to-date and to bring them inline with desired policies and practices. In order to do so (for IANA to take action in modifying the registry metadata), this document needs to be published as an RFC.

The question raised by Werner (as I understood it) was more about how to align the IANA considerations given in 4880bis with this document, and whether to merge the said document into 4880bis. For the intended audience of 4880bis, it seems preferable to keep one-time changes in "draft-openpgp-iana-registry-updates” (such as registry policy updates, renaming, etc), and let 4880bis be a document targeted for the audience of implementers.

Indeed 4880 will have a successor, that is not a “standing document” that is permanently active. It is insofar “living", however, considering the years it took for 4880 to be revised — 4880bis will probably be active for a long time before RFCnnnnbis appears :-)

And fully agree with allowing simple short RFCs to add to the PGP umbrella.

Ron

Ronald Tse
Ribose Inc.

On Nov 28, 2018, at 2:22 AM, Mark D. Baushke <[email-masked]<mailto:[email-masked]>> wrote:

Enjoy!
-- Mark

---

From: Werner Koch <[email-masked]>
Date: Wed, 28 Nov 2018 08:39:44 +0100

On Wed, 28 Nov 2018 06:00, [email-masked] said:

> The question raised by Werner (as I understood it) was more about how
> to align the IANA considerations given in 4880bis with this document,
> and whether to merge the said document into 4880bis. For the intended

Right.  I am not sure what is the right procedure here.  Are the tables
with the various ids in rfc4880bis normative or are the informational
and the IANA registry is the normative reference for them.  For
practical point of view I would like to have the tables in rfc4880bis
to be normative with the note that the IANA registry defines updates to
these tables.

I agree with Ron that the procedures on how to update the IANA registries
do not belong into rfc4880bis.  We need some advice from IETF procedures
experienced people (or a pointer to an RFC describing these procedures).

Salam-Shalom,

   Werner

---

From: Derek Atkins <[email-masked]>
Date: Wed, 28 Nov 2018 13:09:00 -0500

Hi,

> experienced people (or a pointer to an RFC describing these procedures).

Speaking for myself (but with the knowledge of being a former chair of
the OpenPGP WG), it's perfectly fine to put the one-time IANA process
details into the 4880bis draft.  What is often done is to add an
RFC-Editor note to remove the IANA actions section(s) upon publication.

What happens is that the draft will get approved with all the IANA
actions in it, but when it gets edited into an actual RFC, the one-time
IANA actions can be removed.

There is still the historical record of the one-time actions in the i-d
history, but it de-clutters the RFC.

I recommend we take this approach, because getting TWO I-D through the
process will be twice as much work for everyone involved than getting
only one through the process.  We have enough trouble with just the
one.  So I would recommend we integrate in the one-time actions with a
note to remove it upon publication.

>    Werner

-derek
-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 30 Nov 2018 18:19:41 -0600

> > to be normative with the note that the IANA registry defines updates to

Generally you want the IANA registry to be the single normative place to
consult.  It's fairly common to have a table in an RFC and have the initial
IANA registry populated from that (also normative) table, and perhaps less
common but still plausible to have an update document with a table and
instructions for IANA to resync to that table at time of publication (but
still be able to add/change things later).

> note to remove it upon publication.

Derek is absolutely right, here.

I'll note that for TLS 1.3 we did separate documents, RFCs 8446 and 8447,
since there were a *lot* of registry changes and we did want a permanent
record of them, but that split caused a lot of extra work to ensure things
were synchronized during AUTH48.

-Ben

> _______________________________________________
> openpgp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/openpgp

---

From: Ronald Tse <[email-masked]>
Date: Sat, 1 Dec 2018 07:21:43 +0000

Hi Ben, Derek,

I fully agree that managing two documents is more complex than handling one.

However, the OpenPGP IANA update document was created from a suggestion by the Security AD, where the TLS registry update model was the acceptable role model to follow. RFC 8447 is at 17 pages; this document is close to 30 — the OpenPGP IANA registries are numerous and changes to them many, since a lot of them have been dilapidated since the days of 2440.

If we merge this into 4880bis and remove them at publication, we’re adding 30 pages (temporarily) and then maybe removing 25 at publication. And we lose the permanent record that RFC 8447 provides for TLS. Perhaps there is an argument that the registries of OpenPGP aren't as important (!) as TLS’s for permanent record keeping, and therefore should be relegated to an Internet-Draft, but it doesn’t sound like a good reason to forgo that.

Given that the IETF process has already processed the pair of 8446/8447 successfully in a synchronized way, would it be possible that it’s even easier this time round?

Ron

Ronald Tse
Ribose Inc.