Re: [openpgp] [RFC4880bis PATCH] Drop "Compatibility Profiles" section.

Ángel <> Sat, 27 March 2021 03:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 43A0D3A1C3B for <>; Fri, 26 Mar 2021 20:16:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Tft_HCgn86-c for <>; Fri, 26 Mar 2021 20:15:58 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 68C903A1C00 for <>; Fri, 26 Mar 2021 20:15:56 -0700 (PDT)
Message-ID: <>
From: =?ISO-8859-1?Q?=C1ngel?= <>
Date: Sat, 27 Mar 2021 04:15:52 +0100
In-Reply-To: <>
References: <> <> <> <> <> <> <>
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [openpgp] [RFC4880bis PATCH] Drop "Compatibility Profiles" section.
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 27 Mar 2021 03:16:02 -0000

On 2021-03-25 at 23:27 -0400, Paul Wouters wrote:
> On Fri, 26 Mar 2021, Ángel wrote:
> > > I'm attaching the
> > > proposed patch below so that people following the list can see
> > > it.
> > 
> > Hi Daniel
> > 
> > Yep. I wanted it to appear on top of merge_requests/41 but did not
> > find
> > how to do that. Happy to learn how to do that.
> > 
> > Now that Paul has merged your branch, I have rebased it and opened
> > a
> > direct MR against the main repository:
> >
> I had a look at it. While some text indeed is weird because of the move
> from an ECC only document into the generic bis document, I think some
> of the text you suggest removing might still make sense, such as the
> recommendations of hash algorithms for these curves. 

Good point, that table may be useful without the requirement levels.

> And that the place within the document might be right too?

That's an editorial matter, but I don't think so. I find the security
section to contain many things without a clear script, just a mixture
of things related to security. The problem is that most of the rfc has
some relation to security :-)
There are rfcs with only a few security points to note. Having a
section listing all of them is good. But I don't think that's suitable 
for OpenPGP.

I would prefer to see as little as possible on the Security
Considerations, with the points within the most relevant section to the
topic. See for example how I positioned the line about you MUST use
Iterated and salted s2k at the part discussing rather than in that
generic section. IMHO that makes more sense, instead of having a S2K
requisite in a complete separate part of the document.

Nevertheless, the Security Considerations need an overhaul. There are
multiple types of items: general advice, attack descriptions, key size
And it must grow, some of that is outdated, while other missing.

That ECC table I would probably place it at its own section, probably
as a 13.5.

Other points should perhaps be 15.x subsections.

> > (...)
> I agree that needs fixing. The question is how/when to do this. If we
> cut the entire section as you propose, we need to a file a tracking bug
> to re-evaluate what to bring back, revised or verbatim later on in the
> process when we are pulled up all the existing non-controversial work.

I agree with opening a task to reevaluate that later, if merged.
This was not intended as a permanent removal.

> > I think we're better clearing it and seeing what is importable. I may
> > have missed some sentence, but I doubt you could keep most of it as
> > such.*
> I think that could work, but let's get the opinion of a few others ?

> > (*) A phrase that got removed but should be recovered is «MDC MUST be
> > used when a symmetric encryption key is protected by ECDH.». I pondered
> > where to move it, but I concluded that should better go at its own
> > changeset stating that new algorithms cannot be used without MDC i.e.
> > they cannot be used with the "Symmetrically Encrypted Data Packet"
> > (still somewhat redundant, as that one MUST NOT be created).
> If others agree, we need a tracking item for this too?

Yes, probably. Unless we get a quick consensus on this topic.

> > Additionally, the phrase "A compliant application MUST only use
> > iterated and salted S2K"... is also mostly fine, but I had already
> > covered a proposal for that one in the previous
> >
> I would need to hear from more people about this change to see if
> there is consensus for this.
> speaking with no roles others than an individual:

This part was proposed in February on a different thread. I am moving
your comment there and replying in that one: