Re: [openpgp] Key Superseded signature type

"Neal H. Walfield" <neal@walfield.org> Sat, 03 December 2022 15:07 UTC

Return-Path: <neal@walfield.org>
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 E6CDAC1522C6 for <openpgp@ietfa.amsl.com>; Sat, 3 Dec 2022 07:07:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Level:
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
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 Acvm0Q4xtwSs for <openpgp@ietfa.amsl.com>; Sat, 3 Dec 2022 07:07:07 -0800 (PST)
Received: from mail.dasr.de (mail.dasr.de [202.61.250.5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66FD8C1522D0 for <openpgp@ietf.org>; Sat, 3 Dec 2022 07:06:47 -0800 (PST)
Received: from p5de92f23.dip0.t-ipconnect.de ([93.233.47.35] helo=forster.huenfield.org) by mail.dasr.de with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <neal@walfield.org>) id 1p1U6H-0001xt-Id; Sat, 03 Dec 2022 16:06:45 +0100
Received: from grit.huenfield.org ([192.168.20.9] helo=grit.walfield.org) by forster.huenfield.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <neal@walfield.org>) id 1p1U6G-00B6lh-Ir; Sat, 03 Dec 2022 16:06:45 +0100
Date: Sat, 03 Dec 2022 16:06:44 +0100
Message-ID: <875yes4jcr.wl-neal@walfield.org>
From: "Neal H. Walfield" <neal@walfield.org>
To: Aron Wussler <aron@wussler.it>
Cc: "openpgp@ietf.org" <openpgp@ietf.org>
In-Reply-To: <l9nQMx7kDFEUhLWo6aN4ttO1E5Jp-TsKdnTMrbfNn6IgW4mHOXdT2EonIdEJ4neAkRffB9Tmf-eWZTocci2mUqhl3-zqd5xTS2nAlXg6nUM=@wussler.it>
References: <l9nQMx7kDFEUhLWo6aN4ttO1E5Jp-TsKdnTMrbfNn6IgW4mHOXdT2EonIdEJ4neAkRffB9Tmf-eWZTocci2mUqhl3-zqd5xTS2nAlXg6nUM=@wussler.it>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (Gojō) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset="US-ASCII"
X-SA-Exim-Connect-IP: 192.168.20.9
X-SA-Exim-Mail-From: neal@walfield.org
X-SA-Exim-Scanned: No (on forster.huenfield.org); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/scYFj7XT2RhwjQ26Cu_2AxWXFI0>
Subject: Re: [openpgp] Key Superseded signature type
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: Sat, 03 Dec 2022 15:07:11 -0000

On Fri, 02 Dec 2022 22:36:01 +0100,
Aron Wussler wrote:
> I've got another small proposal for the crypto-refresh, also coming from the OpenPGP summit.
> 
> We've been discussing about the options for the v4 -> v5 transition (I guess v6 now?), and I'm a big fan of having multiple independently generated certificates, and allowing a smooth transition between them.
> 
> In OpenPGP we don't have a mechanism to signal a superseded or deprecated key, and I fear that if we all wait for v6 keys to be understood from the majority of software and then atomically switch to v6 revoking our old v4 keys we'll wait for a long time. The alternative is to have two cross-signed certificates, and publishing them both, hoping for people to use the newer one.
> 
> With this proposal, my objective is to have a standardized way to tackle this, by introducing a new signature type that signals key deprecation with a pointer to the new key.
> This would automatically extend to future transitions (e.g. PQC), and allow for an easier key rotation (It would be allowed on hard revocation too).
> 
> https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/222
> 
> All kind of feedback is welcome, whether this means
> (1) not introducing this feature at all
> (2) introducing this feature but later
> (3) introducing this feature now

I like the idea.

As I commented in the MR, I wonder if a new Reason for Revocation
type, `Key is superseded by`, which takes a fingerprint and a human
readable string, would be better than a new signature type.

I also wonder if this should only be respected if there's also a
backsig similar to how a signing-capable subkey needs a backsig to be
considered valid.  Consider: If Alice considers Bob a trusted
introducer, and Bob creates a new key, Bob', it would be nice if Alice
didn't have to explicitly designate Bob' as a trusted introducer.  If
Bob and Bob' certify each other in this way, I would have no problem
considering them to be the same person (the same entity controls both
keys).  If there's no backsig, I'm not sure that this would be safe.

Neal