[openpgp] Re: Call for adoption of draft-gallagher-openpgp-replacementkey

Falko Strenzke <falko.strenzke@mtg.de> Wed, 03 July 2024 06:53 UTC

Return-Path: <falko.strenzke@mtg.de>
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 DCFF9C151083 for <openpgp@ietfa.amsl.com>; Tue, 2 Jul 2024 23:53:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 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, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mtg.de
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 o0ZonNlZUsLu for <openpgp@ietfa.amsl.com>; Tue, 2 Jul 2024 23:53:40 -0700 (PDT)
Received: from www.mtg.de (www.mtg.de [IPv6:2a02:b98:8:2::2]) (using TLSv1.3 with cipher TLS_CHACHA20_POLY1305_SHA256 (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 DAF2BC14CF09 for <openpgp@ietf.org>; Tue, 2 Jul 2024 23:53:39 -0700 (PDT)
Received: from minka.mtg.de (minka [IPv6:2a02:b98:8:1:0:0:0:9]) by www.mtg.de (8.18.1/8.18.1) with ESMTPS id 4636rUL8013988 (version=TLSv1.3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256 verify=NOT); Wed, 3 Jul 2024 08:53:30 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mtg.de; s=mail201801; t=1719989610; bh=0qw6uPMbQil/bNSvMCca4/ty669rGUx5ZqyCk/k5gNk=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=IBtyffma1xLdAeNfnRfX3/wEI0RCYdQJjYqcjXQiegyE9C7zwofy4MR0BydZBeGPR ly/LB6neaGl8OEVobHkXpzUjl7xRkPBLLbmF4v+bdUIk88QknlfD6+6G3jdcZxsdFm 0boeVlfoYv4FU6vNT27FU/ghT44wIa8r6sfhjGpS/pweO8fgF8KDdeE27qLS0UfXiL 1j/oSVPHHLtpfxh8nzAOoQLfdTIL5wUzmNt1GGWSs1Sd0K45isgnA2KmCmfGVE0WhA Ufbm6Xa6N79S3eXKo+iroUFPX+F+cKrecH06jfJ9aqDTYuotsQpOrUid6b4HcIAE9v OA3AcJdi3/Kew==
Received: from [10.8.0.100] (vpn-10-8-0-100 [10.8.0.100]) by minka.mtg.de (8.18.1/8.18.1) with ESMTPS id 4636rTsF009019 (version=TLSv1.3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256 verify=NOT); Wed, 3 Jul 2024 08:53:30 +0200
Message-ID: <87684d9b-1ad2-4b49-ad9b-38b2eb055460@mtg.de>
Date: Wed, 03 Jul 2024 08:53:29 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Daniel Huigens <d.huigens=40protonmail.com@dmarc.ietf.org>, Andrew Gallagher <andrewg=40andrewg.com@dmarc.ietf.org>
References: <87o7anhybr.fsf@fifthhorseman.net> <87jzkunest.fsf@fifthhorseman.net> <87y199g67k.fsf@kaka.sjd.se> <A0B535B4-215B-4159-9F39-0D33C24ECF2F@andrewg.com> <87frvhnhx0.fsf@fifthhorseman.net> <74AAE7BF-BD6C-4F27-9BFF-A4AA972056A4@andrewg.com> <tPdBr7QK7VoBsKag0QafjtDv9mB_jBTxHI00f_gSyM8SnUPkPukP2FqmSc-zcccXkvl13s8pDhnuNr9JkzgnY_XVNJlEEpUpqWvN1Ufw2Jg=@protonmail.com> <64E6E654-BE59-4F7F-83ED-34E9AFA89E52@andrewg.com> <YdQAqCSppzuMJIV23pd0CROjA3ATRR-PLn6ojVQQLi3pJqDnd6KBbLQaDpCa5z3Qlgqe80SFzjzrl5hfwk-m08oBiFM4ppPuyAi3iOOUNr4=@protonmail.com> <25809E9B-BCD2-4205-B4E7-147F72887268@andrewg.com> <-ZhU4QDZerCI_Kt-MHZTrNXJqwhvuFppoGASttd2jNFrH_83B_arkTl8PiUuvcSAg1Rh6ReonATelYM_3muxGnkTbclv9f-3Ssms7cXlAQ4=@protonmail.com>
Content-Language: en-GB
From: Falko Strenzke <falko.strenzke@mtg.de>
In-Reply-To: <-ZhU4QDZerCI_Kt-MHZTrNXJqwhvuFppoGASttd2jNFrH_83B_arkTl8PiUuvcSAg1Rh6ReonATelYM_3muxGnkTbclv9f-3Ssms7cXlAQ4=@protonmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-512"; boundary="------------ms080802030303000106000506"
Message-ID-Hash: PU2ZRIO2KPMDZFHORER5SMAHXICUWW5R
X-Message-ID-Hash: PU2ZRIO2KPMDZFHORER5SMAHXICUWW5R
X-MailFrom: falko.strenzke@mtg.de
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-openpgp.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Daniel Kahn Gillmor <dkg@fifthhorseman.net>, Simon Josefsson <simon@josefsson.org>, IETF OpenPGP WG <openpgp@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [openpgp] Re: Call for adoption of draft-gallagher-openpgp-replacementkey
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/ag3ydYfJAP8l0jd1KDAOu05vOSY>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Owner: <mailto:openpgp-owner@ietf.org>
List-Post: <mailto:openpgp@ietf.org>
List-Subscribe: <mailto:openpgp-join@ietf.org>
List-Unsubscribe: <mailto:openpgp-leave@ietf.org>

Am 30.04.24 um 17:47 schrieb Daniel Huigens:
>> Yes, I did consider that we could define a “trust equivalence” signature that would be closer conceptually (and cryptographically) to a subkey binding signature than to a certification. But I’m not sure that belongs here either, and it certainly opens a lot more questions.
> But I'm not sure we need a new signature type for that; we could just
> interpret a third-party certification with type ID 0x13 (Positive
> certification of a User ID and Public-Key packet) made by a key with
> the same User ID as having that meaning, for example? Then we don't
> need any new mechanism for this.

In the new draft such a mechanism is now specified. Section "4.2 Graph 
topology", however, restricts this mechanism to only be applicable to 
any two keys and not more.

I tend to disagree with the restriction for any key to be able to either 
point to a replacement key or identify itself as a replacement key for 
another key. If one publishes one after another 3 generations of a key, 
say A, B, and then C, then at first key B might contain the RKS to 
identify itself as the replacement key for A and thus establish key 
equivalence binding between A and B. When afterwards publishing C, in 
order for B to indicate C as its replacement key, the key equivalence 
binding between A and B has to be lifted. That seems like a potentially 
disturbing artifact, since a user who still only holds the key A will 
now not see key equivalence binding with B for no convincing logical 
reason. Instead, the graph should be traversable from A to B, then it 
should be checked if C can be used as the replacement and if not, B 
should be checked (or maybe in the other order). For this purpose, I 
think B should be able to hold one or two RKS in order to indicate both 
relations.

- Falko

-- 

*MTG AG*
Dr. Falko Strenzke

Phone: +49 6151 8000 24
E-Mail: falko.strenzke@mtg.de
Web: mtg.de <https://www.mtg.de>

<https://www.linkedin.com/search/results/all/?fetchDeterministicClustersOnly=true&heroEntityKey=urn%3Ali%3Aorganization%3A13983133&keywords=mtg%20ag&origin=RICH_QUERY_SUGGESTION&position=0&searchId=d5bc71c3-97f7-4cae-83e7-e9e16d497dc2&sid=3S5&spellCorrectionEnabled=false> 

Follow us
------------------------------------------------------------------------
<https://360-german-security-alliance.de/> 
<https://www.itsa365.de/de-de/companies/m/mtg-ag>

MTG AG - Dolivostr. 11 - 64293 Darmstadt, Germany
Commercial register: HRB 8901
Register Court: Amtsgericht Darmstadt
Management Board: Jürgen Ruf (CEO), Tamer Kemeröz
Chairman of the Supervisory Board: Dr. Thomas Milde

This email may contain confidential and/or privileged information. If 
you are not the correct recipient or have received this email in error,
please inform the sender immediately and delete this email.Unauthorised 
copying or distribution of this email is not permitted.

Data protection information: Privacy policy 
<https://www.mtg.de/en/privacy-policy>