Re: [openpgp] ECC Curve OIDs section

Ángel <angel@16bits.net> Mon, 01 March 2021 01:49 UTC

Return-Path: <angel@16bits.net>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0723D3A126C for <openpgp@ietfa.amsl.com>; Sun, 28 Feb 2021 17:49:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level:
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id raOQSk4J7FFL for <openpgp@ietfa.amsl.com>; Sun, 28 Feb 2021 17:49:27 -0800 (PST)
Received: from mail.direccionemail.com (mail.direccionemail.com [199.195.249.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBCE53A1269 for <openpgp@ietf.org>; Sun, 28 Feb 2021 17:49:26 -0800 (PST)
Message-ID: <892669d525925be93e6d7358b4c806f9346dd093.camel@16bits.net>
From: =?ISO-8859-1?Q?=C1ngel?= <angel@16bits.net>
To: openpgp@ietf.org
Date: Mon, 01 Mar 2021 02:49:22 +0100
In-Reply-To: <87v9aecg7i.fsf@fifthhorseman.net>
References: <7d8bdda1-4e5c-6c10-f3cd-1d191fad595c@nohats.ca> <4f3d66b74b46b5b8bf27b5e1589bf80e.squirrel@mail2.ihtfp.org> <87a6rug0x5.fsf@wheatstone.g10code.de> <8473b015f635c0f88f9bceed8acda0f8.squirrel@mail2.ihtfp.org> <239af1473534565304e2ecfeca630219417ebc0e.camel@16bits.net> <87v9aecg7i.fsf@fifthhorseman.net>
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/7ZtjwBZsxjGQwtxCW-nk_pHFtaw>
Subject: Re: [openpgp] ECC Curve OIDs section
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp/>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Mar 2021 01:49:29 -0000

On 2021-02-26 at 23:00 -0500, Daniel Kahn Gillmor wrote:
> > I would prefer to see the new section "ECC Curve OID" as 9.5 instead of 9..2
> > The other blocks are clear registries used directly. "ECC Curve OID"
> > are a different case since they are actually parameter inside Public key with
> > certain ids. It's probably as 9.2 because a former draft likely referred to it
> > from 9.1, but that doesn't seem to be the case, and is only referred from other
> > completely separate sections.
> 
> There is a sense that an ECC Curve OID is a subtype of public-key
> algorithms, so putting it closer to public-key algorithms is appealing.
> But i think this argues not for leaving it as 9.2, but rather as a
> subsection of the "Public-key Algorithms" section of the top-level
> "Constants" header (i.e. 9.1.1).
> 
> fwiw, while we're nit-picking, this section ought to be named "ECC Curve
> OIDs" (in the plural)
> 
> Seems like there are three choices:
> 
>  a) leave "ECC Curve OIDs" as §9.2
> 
>  b) make "ECC Curve OIDs" a subsection of "§9.1 Public-key Algorithms",
>     i.e., §9.1.1
> 
>  c) move "ECC Curve OIDs" to the end of the "§9 Constants", i.e., §9.5
> 
> What do other folks think?


I'm thinking that perhaps (d) we should not treat this as a registry at
all, but as an specification for how to produce the Curve OIDs from the
OID themselves (basically, the text below the table, as an spec).
Then make the table itself informational.
This could be kept at section 9 or moved to section 13.
This links with the point mentioned by Werner during the call that
implementing other curves is automatic as they are identified by their
OID.




PS: It would be good to include a note as well at 9.1 mentioning the
public key algorithms which depend on a Curve parameter: ECDH (18),
ECDSA (19) and -when added- EdDSA (22).