IETF Logo Mail Archive

Re: [openpgp] Weird OIDs in the 4880bis draft

Daniel Huigens <d.huigens@protonmail.com> Thu, 09 February 2023 17:21 UTC

Return-Path: <d.huigens@protonmail.com>
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 A2E58C1575CC for <openpgp@ietfa.amsl.com>; Thu, 9 Feb 2023 09:21:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.097
X-Spam-Level:
X-Spam-Status: No, score=-7.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=protonmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aaq80PnhyFeH for <openpgp@ietfa.amsl.com>; Thu, 9 Feb 2023 09:21:50 -0800 (PST)
Received: from mail-4322.protonmail.ch (mail-4322.protonmail.ch [185.70.43.22]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6B1EC1575DE for <openpgp@ietf.org>; Thu, 9 Feb 2023 09:21:50 -0800 (PST)
Date: Thu, 09 Feb 2023 17:21:36 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1675963307; x=1676222507; bh=IMeuXXjoA47xf05Gsa1qBP/oDsQhGe3WIFC61ol6das=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=UzSHpX9q7xckxntmmQQhWjDaKNnsnY203m1YG7LUH4i21+Oqn1QZ/mT5Y0SwrgmKv VVegJRv76M4kGD52fMHN/+BJqMmeGXyP7ljdnt+CAfoOA1mjNaB1F9l8uDXOPvWQiW ySwNEFEou7kuSvt4SBz/BWdrgusi+att0EP+ZgcQ7A4zPiGaj/omTfjLiedNO89duJ 4xMAtE7OF2v+roXdJfHZ1duW3Ewo7sQUsJToXkTdVNGR7DYv9OWLeADsvjKgMC77Ak Q06Tnf96wANUwHpqdYKnUyfD10nuAv9kNcgf9xLd/oyu8rLTbFBHNLn8grBlqI8L6l 8AeEj2SUp7cxg==
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
From: Daniel Huigens <d.huigens@protonmail.com>
Cc: Werner Koch <wk@gnupg.org>, "openpgp@ietf.org" <openpgp@ietf.org>
Message-ID: <FftyrUL2o4WoE4Y7bGeuajBbG_6GJxv_OUHiYOfOtAlo9Ev3bdivyBeU7AkzvAo748CBtrnBEEjetKVZE-JlZkt0fGdosSM34rg1alTDl2M=@protonmail.com>
In-Reply-To: <SY4PR01MB6251ACE71B0B13D3CFB63A7DEED99@SY4PR01MB6251.ausprd01.prod.outlook.com>
References: <SY4PR01MB6251BD1B19BAD5DE910A1C0EEED99@SY4PR01MB6251.ausprd01.prod.outlook.com> <87r0uzuhzr.fsf@wheatstone.g10code.de> <SY4PR01MB6251ACE71B0B13D3CFB63A7DEED99@SY4PR01MB6251.ausprd01.prod.outlook.com>
Feedback-ID: 2934448:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/17TBU3YdsuZBy94p3Yv9jseuqAs>
Subject: Re: [openpgp] Weird OIDs in the 4880bis draft
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.39
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: Thu, 09 Feb 2023 17:21:54 -0000

Hi Peter,

I also think the OIDs are weird :)

That being said, if we truly want to change how we use Curve25519,
there are other things we would (imo) want to change as well, such as
the private key format (which is reversed from RFC 7748). I would then
rather define new algorithm IDs entirely (i.e. one for X25519, Ed25519,
X448 and Ed448 each), without using any OIDs at all.

I say this not as a real proposal at this point as I think it's probably
too late in the process for that. Rather, if we want to do so we could
do so later, and then deprecate these OIDs (or the algorithms entirely).
And/or, once we add PQC, we can learn from our mistakes and introduce
algorithm IDs for Kyber + X25519, for example, rather than keeping
around the OIDs.

Best,
Daniel


------- Original Message -------
On Thursday, February 9th, 2023 at 13:54, Peter Gutmann wrote:

> Werner Koch wk@gnupg.org writes:
> 
> > The one for Curve25519 is from your own arc - if that is not a standard, what
> > else should make up a standard ;-)
> 
> 
> That OID doesn't actually exist, I've never used it or recorded it anywhere.
> Its history is that about ten years ago the Crypto++ guys needed some gap-
> filler value to use because at that time nothing else was defined and I
> jokingly said they could use a random value I made up from the cryptlib arc.
> 
> > The OIDs are in widespread use for many years and we can't replace them
> > anymore.
> 
> 
> Counterargument: The draft is still a draft, not an RFC, which means now is
> the perfect opportunity to fix this problem. If people really have pushed out
> implementations based on an in-progress draft then they can still accept the
> made-up OID value but should, going forward, move to actual proper OIDs.
> Eventually the keys using the made-up value will expire and only the
> standards-compliant ones will remain.
> 
> Peter.
> 
> _______________________________________________
> openpgp mailing list
> openpgp@ietf.org
> https://www.ietf.org/mailman/listinfo/openpgp

v2.23.0 | Report a Bug | By Email