[openpgp] key distribution by email strategy

Kai Engert <kaie@kuix.de> Fri, 11 December 2020 11:22 UTC

Return-Path: <kaie@kuix.de>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id AA5173A0A96 for <openpgp@ietfa.amsl.com>; Fri, 11 Dec 2020 03:22:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 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, 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=kuix.de
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id CezItfK0I6v5 for <openpgp@ietfa.amsl.com>; Fri, 11 Dec 2020 03:22:00 -0800 (PST)
Received: from cloud.kuix.de (cloud.kuix.de []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7731A3A0A7E for <openpgp@ietf.org>; Fri, 11 Dec 2020 03:22:00 -0800 (PST)
Received: from [] (ip-95-223-75-128.hsi16.unitymediagroup.de []) by cloud.kuix.de (Postfix) with ESMTPSA id 3C6B218D069 for <openpgp@ietf.org>; Fri, 11 Dec 2020 11:21:57 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kuix.de; s=2018; t=1607685717; bh=HzSHHfsvV42P/TxQ620ZT3G1L3DUjJvJ9OLso9CcaW4=; h=From:To:References:Subject:Date:In-Reply-To:From; b=DaJocqsIwJfGTddqEiBsZa/A32nWtVsN2v6vePkPHBNAeqPSFKnkceIZ9iF8n04yo H7f7iTgf1zDVsYXv9InG4rqN8+rseGi3Z+Jxsc5rNle7BH6qNB7dvL1nydbYU2G7BB ci4zFhZwmKdZQKP2F/NDli8oL91Dxaqj0f3hPA7zDGRm5AccvQ1VwgHv/ypjLasuO0 5aAueWaZt12DbJlUZ3SJIC1/j6at8KNKbW/3pFbEWn03QlIHFQDVdqsrucwagsyaNI pymsMXlX2vaL5TnkGz16siRW7TCpcRLv7qjd3lkaOszQHPeLzWNLut6F0X/9pPiZA9 N7zOehRV8MJfw==
From: Kai Engert <kaie@kuix.de>
To: openpgp@ietf.org
References: <48be3fcf-cdce-9ef4-655b-63b6dddf9310@kuix.de>
Message-ID: <322cc545-4358-ba95-65d5-3f75b7050c0b@kuix.de>
Date: Fri, 11 Dec 2020 12:21:55 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0 Thunderbird/78.5.1
MIME-Version: 1.0
In-Reply-To: <48be3fcf-cdce-9ef4-655b-63b6dddf9310@kuix.de>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/Ngb1akmo-FdBfZUwbdZ9Vhaft-w>
Subject: [openpgp] key distribution by email strategy
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: Fri, 11 Dec 2020 11:22:02 -0000

Thanks to everyone for your comments and suggestions, it was very helpful.

I wonder if the following could be reasonable.

(1) Similarly to the Autocrypt keydata header
let's define a new header that can be used to transport revocation 
information for a key.

With Thunderbird's current approach to include revocations as part of an 
gpg-keys attachment, we probably cannot expect most other MUAs to 
automatically process it.

Thunderbird would implement the new revocation information header, and 
both send and consume it. With this, Thunderbird would no longer need to 
distribute this information in an attachment.

(2) If the sender's key is simple, don't use an attachment.

Strip certificates, include it as an Autocrypt keydata header.

(3) Develop a reasonable strategy for treating complex keys,
which contain multiple user IDs, or multiple sub keys, or both.

I'm worried that sending a key with only a single user ID can be 
confusing, for example in the following scenario.

Alice's key has two user IDs, @project1.org and @project2.org.

Alice sends a signed email from @project1 to Bob, Bob verifies/accepts 
the key for this email address. Later Alice sends a signed email from 
@project2. Bob will be confused why Alice's key is shown as unverified, 
despite her using the same key. This will require UI to distinguish the 
key verification status individually per user ID.

To minimize this confusion, I think it would be preferable to always 
keep all user IDs, then Bob can be immediately aware that the keys is 
used for multiple addresses.

Does the current Autocrypt specification allow the distribution of a key 
with multiple user IDs and sub keys?

If we strip certificates, but keep user IDs and sub keys, can we expect 
keys to still have a reasonable size for transport in the Autocrypt header?

If yes, then Thunderbird could always include an Autocrypt keydata 
header for complex keys, too.