[openpgp] Hybrid proposal for algorithm identifiers

Phillip Hallam-Baker <hallam@gmail.com> Tue, 24 March 2015 16:47 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id E3A421A6F3F for <openpgp@ietfa.amsl.com>; Tue, 24 Mar 2015 09:47:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id DaAykTcE7KV6 for <openpgp@ietfa.amsl.com>; Tue, 24 Mar 2015 09:46:59 -0700 (PDT)
Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3B561A8AF7 for <openpgp@ietf.org>; Tue, 24 Mar 2015 09:46:58 -0700 (PDT)
Received: by wetk59 with SMTP id k59so168226528wet.3 for <openpgp@ietf.org>; Tue, 24 Mar 2015 09:46:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:mime-version:subject :message-id:date:to; bh=9mc87HgTWMyCTEayQhgTUcNplWuQmu/iDukxwKBJNBo=; b=y28RiyTvqEoxDf3FkafA+7J38PTod/Xlu0gA1frymtaajA8IWzGV3y7KQj1pEw7W13 Vfw3cBFl9+t+ZXYDTQoEII+9Q4932zvY0mhjDSFtjJuINeQiMW/yiwAuwoTW4jDYUCwx AKs1o1IvQr6CllwycqhssFSh/V9dERer9QKkO6IFMMazPMzef8a4tDsAzVrWyfve1onD s9/nN795oPa/NlSF8aYvZDcg2o23s2CpL4TcnIfKyaENd3trD/vIlJmF1+xYiwdvrxnm RpeNR6Zs70upLTsXBP6HVXyR1Ixs+KSdjwb3JDD9CBotdeDodj9rk0r+XyIHYrQJWZrU 5hSg==
X-Received: by with SMTP id y2mr9714102wja.85.1427215617609; Tue, 24 Mar 2015 09:46:57 -0700 (PDT)
Received: from [] ([]) by mx.google.com with ESMTPSA id hi6sm6826147wjc.34.2015. for <openpgp@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 24 Mar 2015 09:46:56 -0700 (PDT)
From: Phillip Hallam-Baker <hallam@gmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
Message-Id: <644FDE72-CB1A-4EBE-9309-B429860A360D@gmail.com>
Date: Tue, 24 Mar 2015 11:46:55 -0500
To: openpgp@ietf.org
X-Mailer: iPad Mail (12B440)
Archived-At: <http://mailarchive.ietf.org/arch/msg/openpgp/nstdb-5f3QcX2p5Z5wgdINHoekk>
Subject: [openpgp] Hybrid proposal for algorithm identifiers
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Tue, 24 Mar 2015 16:47:05 -0000

* Maintaining algorithm registries takes time and effort
* Modern best practice for algorithms rejects the idea that more algorithms is 'better'. 
  * The security of the system is determined by the weakest algorithm an attacker can persuade you to use,
  * One Mandatory to implement plus a reserve is generally emerging as best

* Support for vanity crypto is an unfortunate necessity.
* ASN.1 OIDs are kind of obnoxious
* Suites don't work
* Most OpenPGP folk would like to use short identifiers

For many years I have wanted a way to move discussion of vanity crypto out of the IETF, etc. If we touch a spec, the vendor can pretend that we endorse it.

So what I propose is a two level scheme:

Mandatory and Recommended algorithms are registered in a short identifier registry. 

For everything else there is a reserved 'escape code' that states the algorithm is specified by OID. 

OIDs do get a little large sometimes. But they do have the advantage that nobody can claim that they have IETF endorsement. That is not true of any scheme we could devise ourselves. 

This approach means that there is a real difference between being one of the supported algorithms and the recommended algorithm.