Re: [openpgp] [RFC4880bis PATCH] Deprecate "Revocation Key", replacing with full-key "Designated Revoker"

vedaal@nym.hush.com Mon, 05 August 2019 18:23 UTC

Return-Path: <vedaal@nym.hush.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 AF1A512004A for <openpgp@ietfa.amsl.com>; Mon, 5 Aug 2019 11:23:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hush.ai
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 rTPv0cHJ9JXY for <openpgp@ietfa.amsl.com>; Mon, 5 Aug 2019 11:23:28 -0700 (PDT)
Received: from smtp10.hushmail.com (smtp10.hushmail.com [65.39.178.143]) (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 7F91112003E for <openpgp@ietf.org>; Mon, 5 Aug 2019 11:23:28 -0700 (PDT)
Received: from smtp10.hushmail.com (localhost [127.0.0.1]) by smtp10.hushmail.com (Postfix) with SMTP id B8BCBC0917 for <openpgp@ietf.org>; Mon, 5 Aug 2019 18:23:27 +0000 (UTC)
X-hush-tls-connected: 1
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=hush.ai; h=date:to:subject:from; s=hush; bh=5Oscjc7hqoOb5POduKZ4nuh731azuTdYM60woLxIMU4=; b=nK9lOmf5S082RauBCSCXmWEeivh4XLjGD9nrI1P3rHQYfydPkplF/HiS/mZOb8PN8K07etxFRM+7aUxXLNwpLS+FcxX/DgA+YJUVwAE8JRrBMVk1rUPQ9ND8gNA1cG7JTdOW2Jy2Qgg5Vck8ujpZjfDDwgtn9hVyfU4mo2ik3R4twhrwIPVSveiQA1hpHj0ZQls06TT3Q2MpjwEFO7RL985koMb3vjQ72vHxCbCeNsMe+7v+8Fk1fgp6A9PY+Ilf2afT6MY7fxaR5RzD3SIe8jpAING0YNlsG+PgADo5YxesTaDsoXlMJLtFQV7SkvUh3T8hifRKDDJbeMiPfhKqQg==
Received: from smtp.hushmail.com (w9.hushmail.com [65.39.178.29]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp10.hushmail.com (Postfix) with ESMTPS; Mon, 5 Aug 2019 18:23:26 +0000 (UTC)
Received: by smtp.hushmail.com (Postfix, from userid 99) id AC15E20118; Mon, 5 Aug 2019 18:23:26 +0000 (UTC)
MIME-Version: 1.0
Date: Mon, 05 Aug 2019 14:23:26 -0400
To: Werner Koch <wk@gnupg.org>, Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Cc: IETF OpenPGP WG <openpgp@ietf.org>
From: vedaal@nym.hush.com
In-Reply-To: <87wofrmrry.fsf@wheatstone.g10code.de>
References: <87iocqepta.fsf@littlepip.fritz.box> <20190731203444.4822-1-dkg@fifthhorseman.net> <87wofrmrry.fsf@wheatstone.g10code.de>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20190805182326.AC15E20118@smtp.hushmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/DewaYAaKG3Kg_4yF-jPAHVBYsZU>
Subject: Re: [openpgp] [RFC4880bis PATCH] Deprecate "Revocation Key", replacing with full-key "Designated Revoker"
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, 05 Aug 2019 18:23:30 -0000

On 8/5/2019 at 1:45 PM, "Werner Koch" <wk@gnupg.org> wrote:

>I view this as problematic in the light of our preparations to 
>allow for
>larger key material.  With PQC we may need megabyte large keys and 
>then
>including an entire key would double the size of a keyblock.

=====

There is a workaround which could avoid this;

Generating a Revocation Certificate for the key, and keeping it in a separate place from the keyring,
and also sending it to whomever the user wants to be the 'designated revoker', 
(which could change from time to time, without having to update the keyblock itself).

If this seems reasonable, then maybe consider it as a 'suggestion/comment'  to the rfc section dealing with revocation.


vedaal